HN user

jackdied

58 karma

Python-dev, serial startup guy in Boston.

Posts3
Comments39
View on HN

Cambridge, MA. HiveFire, Inc

Software Engineer, Engineering Manager, UI/UX Frontend (http://www.getcurata.com/careers)

Small Django/Python shop. We make a curation product and have actual customers who pay us actual money (crazy concept, I know).

As part of the engineering team you will work on a bit of everything: front end, NLP pipeline, database, devops, support. And if you're a bowler you can join a bunch of us in the Wednesday night league at Lanes & Games.

Sadly no, but now I know for sure you aren't Jim Baker (the jython commiter).

Most python users have never heard of anyone other than Guido. That's fine because people who contribute to open source projects don't do it for the fame, and that's reasonable because you can't be expected to memorize the names of all the people who wrote the tools you use. That said, it can be frustrating being not Guido (Brett gets heaps of credit inside the community but zero percent of Guido's name recognition).

1st story: my first PyCon I went out to the smokers deck and introduced myself (this was '02 or '03 - I'm not sure we even had name badges). The other guys turned out to be Tim Peters, Christian Tismer, and Alex Martelli. Python jackpot.

2nd story: I told that first story to a random lunch table of people at PyCon last year (as a rule I eat lunch with no one I know at cons) and the collective reaction was: who?

So yeah, don't feel bad about not knowing who Brett is (but do buy him a beer if you run into him). And definitely don't get involved in open source for the fame. [Bonus trivia: Gustavo also has a commit bit, as do a couple other people in this thread]

Jack Diederich (my nick is an old UNIX login, "jackdiederich"[:8]). I'm an invited speaker this year so I'll definitely be there.

At least two automated trading firms sent contingents to PyCon last year so you won't be alone (I think both were state-side). As for microbrews? Although it started with states that had odd blue laws for liquor licenses (limited regular licenses but unlimited for on-premises brewing) you can now find micro-breweries in every major city and most minor ones. PyCon always has a beer BoF group.

"Ruby does it this way and people like it" isn't an argument that will work. You can accomplish the same things in Python with an extra line of overhead.

If you want to get this past python-dev you'll need to explain the benefits, here's a start:

1) Lower cognitive load: Users can understand blocks but the extra naming/reference is one too many things for their brain stack to handle.

2) More descriptive: with blocks the first line says "I'm about to define a function for use with X" instead of the existing way which says "I'm defining a function. Now I'm using that function with X."

3) Show me: take a chunk of an existing project (stdlib is best) and rewrite it with the proposed block syntax. You get to cherry pick the example so if the new version doesn't read much cleaner than the old version maybe the idea isn't so hot.

I'm -1 on the idea but if you want to change my mind you have to make an argument that doesn't start with "In Ruby..."

As a sometimes Python core developer allow me to say stuff. The main goal was to remove mistakes; an all-at-once deprecation. The release was actually much less ambitious than the original name "Python 3000" implied. Guido read one of Joel's posts on rewriting software [the one on the Mozilla rewrite] and dictated that 3.0 be done in a year or two. See the list of PEPs [Python Enhancement Proposals] for silly big changes that were shot down.

As for python 3.0 being 10% slower than 2.5 - that means that it is is just 1.9 times faster than Ruby instead of a clean 2x? And the backwards incompatible version took just two years instead of infinity like Perl and two years instead of the UNK for Ruby? Python 2.5 benefited from a corporate sponsored "Need For Speed" sprint where twenty of the core devs went on a paid vacation with a mission to just sprint on speed issues. There hasn't been a corresponding sponsored event for 3.0.

A huge amount of volunteer time has been spent on backwards compatibility issues. When the Python 3.0 issue was first floated the Twisted and Django folks had lots of worries about the transition and supporting two versions (2.x and 3.x). Hundreds of hours were spent on the email lists and PyCon dinners hashing out the details. Thousands of hours were spent adding warnings and best practices docs to 2.6 as well as on the "2to3" translation tool.

Time will tell but there will certainly be lessons learned from the Python 3 release.

Long story short: CPython uses a custom memory allocator on top of the OS malloc because some mallocs are really bad and python knows more about it's memory usage patterns than the OS. The newer CPython allocator plays better with popular OS's so that repeatedly newing and freeing lots of objects is more likely to return memory to the system.

The old behavior didn't effect server sized systems and typical workloads but it did piss off some embedded apps.

If you are asking for introductory economics +1 for "Basic Economics" by Sowell and "Free to Choose" by Milton Friedman (Sowell is one of Friedman's proteges).

PBS made "Free to Choose" into a series back in the 1980s. You can find all the episodes on YouTube.

And that reminds me of my CS professors who used file timestamps to determine if you submitted by midnight. The TAs were the ones who checked the assignments and they got around to it .. eventually. Clever man that he was the prof gimped the "touch" binary on that system to accept no arguments. Sadly for him Stevens includes source for a simple touch program in "Advanced Programming in the Unix Environment"

Clever, but as others pointed out likely to anger anyone who has to read your code.

NB: python bitwise operations are not super fast like in C. They don't get optimized down to single CPU instructions but instead are looked up like regular type methods (e.g. __str__ and __add__). An "ob[~0]" won't kill you even in a loop but don't bother translating simple math into bit-twiddling because it won't help (and might hurt if it inflates the number of operations).

1) Yes, this doesn't belong on YC

2) Superdelegates are supposed to make the kind of calculations you are suggesting. They have a big advantage in that they vote last so they know the most up-to-date breakdowns of the individual states. Superdelegates are immune to the cross-party registration (Rep voting in Dem primary) and are more likely to listen to actuarial opinion - you could provide the same info to the voting public but it wouldn't change votes much. That's the theory of Superdelegates anyway.

Fark isn't in the same ballpark as reddit and digg. The only users that get to vote on stories are the core users who have ponied up $50/year for a totalfark membership and I believe only the admins can put a story on the front page. All the filtering is done by the core group who has incentives to keep the links on topic (if fark can be said to have a topic).

/farker but not a tf'er

Daylight savings is a feel-good scam and always has been. Congress gets to look good by being "green" at the cost (to them) of zero dollars. Of course the rest of us have to pay for the tampering - last year's change personally cost me at least a thousand dollars because I spent time updating and checking servers and libraries instead of doing something useful.

Zed Shaw on Python 18 years ago

The Python community has the advantage of being older. The fanboys (if there were any) have moved on or calmed down. The libraries and documentation have had more time to be beefed up. A few years can make a lot of difference.

For the same reason that open source projects are started by one guy with running code and not by committees talking about what to do. Everyone with an opinion isn't necessarily your customer - they are just guys with opinions.

You could be non-secretive without being interactive or not taking opinions. But that seems like burning PR early for a product you will be releasing soon anyway.

Do talk with people who's opinions you already value. But you aren't Microsoft so pre-announcing a product won't intimidate others into not competing with you and it won't whet potential customer's appetite. Make something you know you would use and then see how others like you respond.

The story of stuff 19 years ago

Please see reddit for your anti-capitalist green ranting needs.

"You can't run a linear system on a finite planet indefinitely." I'm going to drop that one at a cocktail party and count how many people nod versus sigh.

Wow, that guy has strong opinions on lots of things and he isn't afraid to share them. (did I understate that adequately enough?)

Edit: but the dtrace part is very good. Around the 1 hour mark he starts demonstrating using dtrace to instrument the python parser. Good stuff.

Definitely, you don't want to scan the filesystem to do searches. But finding user 1234's profile in profiles/1234.data is easy. In my experience this works well (even with the wasted space) though operations like fsck start to get painful when you have 1 million+ files.

An anecdote on bad linear search: in the 90s I worked on a system in C++ that made heavy use of inheritance and other C-plus-plus-ery. There was a bunch of file opener classes each that found files in a different way (regexp, straight path, glob). They differed only in a method named match. The base class called match on every file name in the directory until it returned true. That was fine for regexps but even if you opened a file _by name_ it took N/2 syscalls to readdir to find it! This worked OK until someone created a directory with 10k entries on a production box. Ouch.

SQL is good for doing arbitrary queries. Most web sites don't need to do that!

Look at duels.com (a simple player-vs-player game). On each page it needs to know your stats/equipment and that of the person you are dueling. In an SQL database you might store the person/stats in one table, the inventory in another, and the fight record in yet another. In SimpleDB the stats and inventory could be in one domain with fight record in another.

SimpleDB or even dumb file-per-player based systems don't pay the overhead for allowing arbitrary queries so they scale better. Your SQL store will be slowed down by the weight of inactive players and their inventories and all the indexes and data they have lying around. Using in-memory caching (like memcached) is a popular way to pay the SQL cost less often while keeping the arbitrary-query ability on the back end.

And of course don't forget that SimpleDB is hosted by a farm of machines tweaked and maintained by someone else. Your MySQL setup will never be that cool.

Edit: and as for XML,if you add that to SQL, well now you have two problems.

I do just that with mutt. To add notes to an email hit 'e' and it fires up the raw email in emacs (or your favorite editor). Just add comments and save it.

Mutt doesn't have a fancy UI but it is fast. It has no problem handling the 150k+ in my inbox (mostly unread). I know some people that swear by pine and for all the same reasons. YMMV.

Yes, but it is a hard thing to plan around. Can you really know who might want to buy you?

Good advice from an old boss: DO NOT include words like kludge, bug, garbage, or swear words in code or checkin comments. All production code has kludges, bugs, and fscking garbage in it but making it easy for a due diligence auditor to grep it can't help.

[True story, at MusicBlvd.com I was ordered to write a SUID root program to move html files from staging to production directories. I protested but wrote it anyway and named it kludge.c. After we were bought by CDNow I found out they had a SUID root bash shell on _every single frontend machine_. Kludge indeed.]

First, your post would have been comedy gold if those had been real demo URLs.

Second, consider making the demo launch a POST from the landing URL. That should stop the crawlers you won't have in the first place.