Phillip J. Eby

A bit dated now, but still a great read about a Python project done by Java developers: http://dirtsimple.org/2004/12/python-is-not-java.html "So, the sad thing is that these poor folks worked much, much harder than they needed to, in order to produce much more code than they needed to write, that then performs much more slowly than the equivalent idiomatic Python would."

> A bit dated now, but still a great read about a Python project done by Java developers: http://dirtsimple.org/2004/12/python-is-not-java.html I included a link to this blog-post in the "letter of intent" (don't know the exact English term) that I sent to my potential employer just before my first interview for a professional (Python) programmer job, back in 2005. I got the job. Good times.

> Those who don't study Zope are condemned to reinvent it http://dirtsimple.org/2007/01/where-zope-leads-python-follows.html https://github.com/zopefoundation?tab=repositories

Let's put that another way: if you're not afraid of being seen as the dark lord of an evil empire in order to get what you want (which, in Gates' case, seems to be "billions of dollars to solve the most important problems the world has to offer") then you should follow in his footsteps. In other words, if you have world-changing vision, and want to succeed on a truly massive scale, you probably have to Think Like A Supervillain (http://dirtsimple.org/2009/02/everything-i-needed-to-know-about-life.h… http://lesswrong.com/lw/gp7/think_like_a_supervillain/).

Have you thought about getting your GED? Maybe the reason why you're unmotivated by schoolwork is that it is useless to you. What types of activities do you find difficult to do? Cleaning toilets, doing math problems, writing reports? One technique that I use is stolen from PJE (http://dirtsimple.org/2006/01/smelling-fear-feeling-future.html), The "Mmmmm" test. Generally you're doing these things to get something else that you find worthwhile. If you can visualize this goal deeply enough to change your emotional state, like Homer Simpson fantasizing about donuts, then you can associate it with the thought of doing the drudgery as well. It takes time and effort to retrain yourself to do this, though.

I used to intern at MS and have used .NET platform for a while (on and off, including not too long ago doing a bit of ASP.NET, ASP.NET MVC, and Sharepoint for one-week project). I've used VS.NET 2005, 2008, and 2010. I've also used Java for a while, the whole Spring MVC, JEE6, Eclipse, IntelliJ. If you're willing to live in Windows OS platform, you should go with .NET, no question asked. Forget about tooling and everything else. If you want more flexibility, more choices, etc, Java is your choice. (There's also Python, Ruby, and the rest but let's scope it to Java). .NET culture is heavily influenced by the culture of Microsoft which means: 1) Less Open Source, More mISV (more "pay" products) 2) Windows/GUI, less command-line (has changed a bit but still not there) 3) Fire and Motion http://www.joelonsoftware.com/articles/fog0000000339.html #3 is important because MS makes money from tooling as well. When I was there, the internal chatter was "tool will be out of date every 2-3 years". Please make your own conclusion. Some people said Java had this period of "sleeping" which was true. But during that time frame, we've seen TONS of open source projects that are very mature, battle-tested, and probably everlasting. We've also learned a better way to write Java code (HN made such a big deal of Factories yet HN never acknowledge the best breed of Java code out there, it's a typical of a community like this anyway). Thus that "sleeping" period is being used efficiently…

Article like this needs to be sliced-n-diced in different ways: 1) If you don't know technology X and use it due to hype, you deserve to get burned Let that be a lesson for anybody. 2) There's no silver bullet Choosing node.js over web-framework just because you want the front-end and the back-end to use the same code-base is to trade one feature for another: Ruby and Rails still have better tools than Node.js while you get JS all over the place (assuming you're good with JS). 3) Complaining about the language is a sign that you have no clue I used to think that Java is better than some of the hype dynamic languages out there but I was wrong: Java is better for ME because I _KNOW_ Java Better. If I know Ruby more than I know Java then Ruby is better than Java FOR ME. 4) Don't program using another language's idioms This is documented left and right already. If you use technology X, find best-practices for technology X. Don't just apply best-practices from technology Y. http://dirtsimple.org/2004/12/python-is-not-java.html Or some of the comments here about Dependency Injection (which is quite common in Java but not so in Python/Ruby). In the past, I had one instructor that noticed that my QBasic code looked like Fortran. He asked me if I knew Fortran beforehand and I told him that I've taken Fortran before this class. People see and notice.

Your personality seems similar to the one I had at 15. Here's what I wish I had told myself. All of your problems stem from your internal ape perceiving itself to be at the bottom of the social hierarchy. For example, right after sharing that you made $21K in a programming contest at age 15, you immediately downplay your accomplishment. You are part of the "careful, pessimistic thinker" class of nerd--the kind of nerd who could write space shuttle software for NASA. Most people are overconfident in their beliefs and overrate themselves, but not you. (It's a pretty good sign that my diagnosis is accurate if you find yourself instinctively denying its truth. Overconfident people rarely think they might be overconfident.) Being a careful, pessimistic thinker has pros and cons. Your model of the world will be better than average, and you'll have a good idea of where its holes are. On the other hand, your psychological health will be below average since you instinctively scrutinize everything looking for flaws--including yourself. There's a lot to say about how to fix this problem. Fortunately, I've managed to fix it in myself, and I now have really good psychological health (procrastinating very rarely) while still being able to scrutinize everything I do and figure out how I can do it better. (In fact, my scrutinizing instinct was actually pretty useful for improving my psychological health once I learned to apply it properly.) I read a good quote by a…

Don't put me on a pedestal or anything; my so called "years of experience" cover my first decade of adulthood, basically being "a loser" or at least not developing a lot of potentially good opportunities. It's only in the last three months or so that I've found this approach, which is PJ Eby's work. I don't know what to say about it - I could (edit: will!) write a lot about it, but since I'm so new to it it might not be accurate or present it well, but I'll try and summarize, and I can link you to some more good stuff (see below). Anyway, the main bits are an overview of how humans learn behaviour: we animals have brains to model the world around us and predict when situations are going to be good or bad for our survival. Those parts of our brain signal using feelings - we get alert and nervous at a sharp twig snap, spooked when all the noises around us suddenly stop, pleasant anticipation for friends showing up, anger at enemies showing up, etc. That signalling happens whether a situation is happening or if we just imagine it happening. Along the way in our normal lives we accidentally learn a lot of these {situation -> feeling} links which are unhelpful or tied to really dumb / irrelevant things, and they guide our behaviour too. Things like: once upon a time if we were shunned by the group we would starve to death, so being shunned by people generally is a bad thing. We might bring a drawing to show and tell and the teacher makes a comment and the class laughs. Some…

Have you read "Dreaming in Code"? This is a key theme in one section and I recall it was quoting Philip Eby https://dirtsimple.org/2004/12/python-is-not-java.html

> One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". Not exactly a novel take: https://dirtsimple.org/2004/12/python-is-not-java.html

I actually read a post today that had a similar story about IKEA-like furniture. http://dirtsimple.org/2009/05/how-we-get-stuck.html TL;DR: The author's SO got stuck trying to assemble a kitchen cabinet, and couldn't figure it out. The author looked at the problem, checked with the manual, discovered the solution immediately, and got called smart. The SO didn't even bother. And the author realizes that if their positions were swapped, he wouldn't bother either. There's something wrong with the whole class of people - that mostly seems to coincide with the "non-tech" group, though maybe it's more about problem-solvers/not problem-solvers. What's wrong is that they get stuck on the first obstacle and give up. Instead of assuming that there must be a simple solution and searching for it, they assume it's broken and quit. Also, related, the famous XKCD chart: https://xkcd.com/627/.

> Django's event system lets you avoid polling the DB. Django's signal system must be run on the same instance, synchronously, before returning any response to client. This means if a signal blocks, the response will never reach the client. It's technically impossible to handle post-response events in WSGI. http://dirtsimple.org/2011/07/wsgi-is-dead-long-live-wsgi-lite.html For example, user requests a blog post, you can't first return response then increase your view counter by 1. You just can't. Unless you use some container specific hooks (like uWSGI, Tornado, etc.)

Absolutely. I have not seen a factory pattern in use in ages. I think the last time was before http://dirtsimple.org/2004/12/python-is-not-java.html was around.

In addition to this, I recently discovered that Flask doesn't support Transfer-Encoding: chunked (which is part of the HTTP/1.1 spec), and doesn't fail gracefully either (when receiving a chunked request). Then I discussed it with Armin and realized that the WSGI spec prevents Flask from doing either. (See also http://www.b-list.org/weblog/2009/aug/10/wsgi/) Time to fork WSGI? ETA: Upon further investigation, there's a big discussion out there on what to replace WSGI with, here's one entry point: http://dirtsimple.org/2011/08/is-wsgi-lite-library-or-protocol-and.htm…

What middleware do you think are missing? In general, stuffing application logic into middleware leads to problems, so I don't think your premise is sound. http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html I think your approach is harmful and will put developers who use this library in a very bad situation. You are putting a simplifying abstraction on top of HTTP. As with all simplifications, things which do fit perfectly in your tool become very easy, and things that don't fit perfectly become completely impossible. Finally, I stand by my argument. Werkzeug and WebOb let you put the exact kind of simple interface on top of WSGI that you are attempting to, but with the benefits of not restricting you to a subset of HTTP, and interoperability with awesome tools like mod_wsgi.

> It's always easier to expose something later than to make it private later. ...if you're using Java, since (AFAIK) you can't switch between public fields and getters/setters. Python, however, has properties: http://www.python.org/download/releases/2.2.3/descrintro/#property . Point 4 of http://dirtsimple.org/2004/12/python-is-not-java.html covers why they're a good idea, though you can probably figure it out from their description.

If you ignore the fact that this page is a bit biased towards python, it is a pretty good intro to Python if you're coming from a C++ or Java background: http://dirtsimple.org/2004/12/python-is-not-java.html My personal experience is that the Java-ish languages encourage you to overthink problems a bit. Instead, I suggest that you just do what comes naturally. This will actually get you pretty far, as Python doesn't have that many gotchas (at least in comparison to Java or especially C++).

> For example, to store a graph in a RDBMS, the ideal format is probably an adjacency list with a recursive query to iterate it I know this was a minor point, but I think it speaks to the overall topic, so I'll poke at it. Adjacency lists are perhaps the worst way to store a graph / tree in RDBMS. They may be the easiest to understand, but they have some of the worst performance characteristics, especially if your RDBMS doesn't have Recursive CTEs. This starts to matter at a much lower scale than you might think; several million rows is enough to start showing slowdowns. This book [0] (Joe Celko's Trees and Hierarchies in SQL For Smarties) shows many other options, though it does lack the closure table approach [1], which is my preferred approach. And here, we come full circle back to the long-held friction between DBs and applications. You start mentioning triggers, and devs flinch, stating that they don't want logic in the DB. In every case I've ever seen, the replacements they come up with is incredibly convoluted and prone to errors, but hey, it's not in the DB. There is no reason to fear triggers, if and only if you treat them the same way that you'd treat code (because it is): added/modified/removed only via PRs, with careful review and testing. [0]:…

factory_client does whatever you want it to do - it's just the method that would call your Abstract Factory or Factory Method or whatever. I've never used Spring, but I assume that the wiring it does is similar to JSF managed beans, eg. you give it an XML config file and it takes care of creating the appropriate Java objects from that. As for how you'd do it in Python - you wouldn't. To quote Phillip Eby: "XML is not the answer. It is not even the question." http://dirtsimple.org/2004/12/python-is-not-java.html That's because XML is usually easier to write than Java but harder to write than Python, so you're better off just writing the Python. You'd write your classes, and then stick them in a data structure somewhere. You could even use the package structure of your app as that data structure - have the client code receive a module (modules and packages are first-class in Python), then use getattr to pull out the class object. Then when you have a class object, you call it to create a new instance. I suppose if you want some security guarantees, you'd explicitly specify the classes that may be passed in to the method. For example, in my own app, I have a bunch of classes that essentially represent language constructs in a visual domain-specific language, each of which has a "default" value so that when the user's clicking away they don't have to type in code from scratch. I wanted to expose these defaults to JavaScript, the language of the UI. So I put…