Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

(Note: This article, while good, is from 2007 so perhaps its advice is slightly out of date.)

Personally, if I were going in completely blind I'd choose Python (with C as a backup). Numpy and Scipy are fast enough for most of the things that you need to do. It's the "it does pretty much everything" language. Is it great at very high performance games? No. But you can drop into C pretty easily (although I find Ruby + C to be easier) and most of the code you'd be writing isn't going to be core game logic.

Now as to why I'm not coding it now: Because I know what I'm building: Dynamic web apps. Ember (with EmberUI) + a pure Rails JSON backend (with xdomain) will get me there much faster than the needlessly verbose Python. It will also let me hire people that won't have to figure out my stack. It is simpler and less risky. I'd never write this in C.

View on HN

What projects on the scale/complexity of Photoshop are implemented in Python? Possibly large chunks of Youtube or Dropbox?

I love Python for small scripts, and even don't regret it too much for programs with mild complexity (~5000 lines of Python), but the lack of explicit typing makes figuring out what any given function/class does pretty hard. What are the arguments? What do they do? What does the return type do? Where is this thing initialized? Finding the answers to those kinds of questions are greatly aided by an IDE/source code browsing that is anchored by types.

Yelp is a multi MLOC Python code base. AFAIK YouTube is slowly being ported from Python to Go.

There are plenty of other large codebases in dynamic languages:

  - Wikipedia and Facebook written in PHP
  - Twitter was originally written in RoR

To be honest, it's my personal opinion that good static languages (i.e. type inferenced) are better than dynamic languages. I believe it's situational compared to traditional static languages (e.g. Java, C++).

Both twitter and facebook ran into some pretty hard limits on those platforms which in the case of twitter led them to abandon RoR and in the case of Facebook led them to create a compiler for the language (doable on that 100M budget but still quite an undertaking).

"needlessly verbose Python"... For me Python and Ruby are right on par. Could you elaborate further ?

Part of Python's mantra is "Explicit is better than implicit"[1] which I fully, and wholly disagree with. You end up with a file that has 10 import statements and on larger codebases this just get worse and worse. Furthermore, this leads to less DSLs and other helpers that Ruby is just better at.

In Ruby (or possibly just Rails?) say I want to get the start of the day 3 hours from now, when a sports game is supposed to end, say.

I go (Time.now + 3.hours).end_of_day whereas in Python I have to do "import datetime" (Or is it "import timedelta"? Let me Google) Then I need to do this: http://stackoverflow.com/questions/7985756/whats-the-most-el...

And it's like, how many times do I need to Google Datetime and timedelta. Let alone getting into the weeds with different time zones and daylight savings time changing its calendar day. I could show other examples: Why do I have to pass self into a method when that is the default thing I want to define in a class?

And you can call this all petty bickering but when you sometimes work in machine learning and your model takes 45 minutes to train and to be told by Python that you forgot to import the production configuration file, it's just such a drag. And I know I can type "import *" or include something in my __init__.py but then people will think I don't know what I'm doing. Also what is with "def __init__(self)"? Why isn't it def initialize? Like, the first thing we tell new programmers is that "__" means "warning, don't use me unless you really know what you are doing" then the next thing we say is "go ahead and change __init__ though, that is normal.

1. Type "import this" in a Python REPL to read the full thing.

    <?php

    $threeHours = strtotime("+3 hours");  
    $startInUnixTime = mktime(0,0,0,date("n",$threeHours),date("j",$threeHours),date("Y",$threeHours)); // had to check php.net/mktime

But, and I am a Ruby neophyte, someone, not the language designer, wrote a library / DSL that somewhere has "end_of_day" defined.

Now I would never ever trust that this nice person got end of day right for my 100M project. Because they cannot. Is that end of day as in close of business or as in midnight? Is that end of day as in the time some we start that process in ? Or end of day as some arbitrary cut off for a global company (frequently in my experience it's a New York day whereas every library starts using UTC). Don't start on leap seconds, leap days, process allocates that can kick off your code on a machine in HK or NY.

Really this stuff needs to be written as a stdlib in the organisation using it. Datetime might be verbose but I can read that code and see what it does in any python program - "end of day" is something I need to go and find the underlying library for.

It's ok to add tests for code you didn't write.

I was just meaning that a single line of code with "end of day" in it would almost certainly not meet my needs.

It is worthwhile exploring the date-time-calendar libraries and adding tests and third party addons that meet my needs - yes. But I will almost certainly need to do work - out of the box rarely works for something so complicated as dates. And that extends to a hell of a lot of other stuff to

Mostly I guess I am grumpy that "do what I mean" does not work very well.

The bit where you don't know for sure what's in Ruby and what's Rails-specific, argues against your own point for me. I can't help but feel that that sort of attitude is why the more work I take that involves maintaining Rails applications, the less I want to write a new application in Rails... I'd consider using just plain Rails, though my experiences with the code quality of even some aspects of that aren't super great, but most 3rd party Gems for Rails scare the crap out of me at this point in terms of future support burdens. And people throw so many of those into their gemfiles.

  2.1.0 :002 > Time.now + 3.hours
  NoMethodError: undefined method `hours' for 3:Fixnum

  2.1.0 :003 > Time.now.end_of_day
  NoMethodError: undefined method `end_of_day' for 2014-12-27 20:52:11 -0600:Time

EDIT: to elaborate on what I mean by that sort of attitude, I feel like Rails's reliance on "magic" (or things that appear to be such) makes it too easy to do things quickly that the cost to do it right doesn't get paid and this interacts very badly with a common pitfall for users of open source components where people just don't put in enough time vetting quality before integrating things into a project.

See, I actually knew that it was just part of Rails, but this is my whole problem with the Python community. They have this explicit is better than implicit attitude that infects their appreciation of what makes code good.

Code is good if it is legible. Doing things quickly is good. Nobody actually writes "end_of_day" and doesn't expect it to work outside of a rails project without running it or testing it.

The Ruby community doesn't need to clutter up their codebases with senseless imports to make programming fun and useful. And people hand wave about how 3.hours is cluttering up codebases, but it really isn't. What clutters them is broken frameworks or abandoned protocol buffers. Rails (and ember) have this amazing idea that code shouldn't be anymore verbose than is necessary and Python just doesn't have that.

Reply on news.ycombinator.com