4 ms·

So I probably agree with you more than you think, but I'm trying to tilt the scales towards dynamic typing a little to counteract any bias I may have from the f

So I probably agree with you more than you think, but I'm trying to tilt the scales towards dynamic typing a little to counteract any bias I may have from the fact that all my work with static typing has been with talented engineers and all my work with dynamic typing has been with garbage ones. I agree with you about there being no concrete advantage to not being forced to specify the type of something; honestly, I don't even like type inference in eg C++ all that much, except as syntactic sugar over really ugly template types for whom the type just pollutes the code without adding any signal. But for example, I don't even really see the advantage of using auto in: for (Widget widget : widgets) { That being said, I do believe there is a concrete flexibility advantage, that I pray you never need to take advantage of but that sometimes can't be avoided in seed-stage startups. There were a couple of times where I monkey-patched the definition of a function (including an external library once! Oh the shame...) in order to get something working for a sales demo, and we just wouldn't have had the velocity to take shortcuts like that in a language like Java or C++, though I would personally make the fixing of the hack a P0 or at least a P1. These kind of "intentional bugs" allow you a bit more flexibility with using tech debt, and in the hands of skilled enough engineers, can provide you with boosts of velocity when you need it in the short term (at the cost of overall velocity). Similarly, some pretty nifty stuff in libraries is possible due to the flexibility of these languages. I'm not a huge fan of frameworks in general, but my understanding of Django's ORM is that it compares quite favorably to ORMs in other languages. Given the amount of times I needed to do database surgery on prod (did I mention how much this company sucked?), it was a lifesaver to 1) have such an expressive interface to the DB and 2) have both an interpreter in the same language as our code and the ability to import and run production code. I'd imagine that pretty much every part of this would be more difficult in a less permissive language.

scarface74 8y ago
I’m just started to get into Python and I generally don’t see the point of ORMs since they really don’t add much in my opinion. I’m really curious about Why you like the ORM for Python. The only ORMs I’ve ever found useful are those based on LINQ because LINQ makes any ORM (and whatever you call the Mongo LINQ driver) first class citizen and it integrates into the language.
- wutbrodo 8y ago
  I have the same rough opinion of ORMs in general and I've never had the occasion to examine it: it was the right choice for our org because there's no way in hell the engineers were going to learn to write good SQL when they could barely write good Python, especially when I'm far from a SQL expert. I was at the time capable of writing good SQL (presumably after a ramp up period), but I doubt my capability to teach it well without significant time investment. The ORM was a path of least resistance thing, providing a simple, easily-comprehensible interface in the language they were already writing. In the specific context of stuff-is-on-fire, production database changes (I'll reiterate, this place sucked), the fluency of the ORM and its seamlessness with our code was helpful. I don't know much about LINQ, but I gather that the syntax is declarative, which is a perhaps-minor speedbump that would nevertheless have made me less fluent in the specific above-described scenario. In the general case of engineering, LINQ looks like something I would far prefer. This isn't a criticism of your comment or anyone else's, but I have to say I'm amused by how all of my responses downthread of my comment are in defense of me being charitable towards more permissive languages (as I said, my bias probably swings solidly the other way, and if I never engineer in a permissive language again, I'll die happy). I kind of assumed it would go the other way, with HN jumping on my comment as elitist or something.
  - scarface74 8y ago
    Every other ORM is bolted on. For instance if you write the following using LINQ: var x = from c in customers where c.Age > 65 && c.Sex == “male” select c; var results = x.ToList(): If customer represents an in memory list, it gets translated as regular old compiled code. If customer represents a sql database table - it gets translated to SQL and run on the database server. If customer represents a Mongo collection. It gets translated to a Mongo query. Of course you can do stuff like switch out what customer represents at runtime and it will be translated appropriately. You also get autocomplete help and compile time type checking. You can pass the where clause around: var expression = c.Age > 65; And pass it into a method.
zozbot123 8y ago
> Similarly, some pretty nifty stuff in libraries is possible due to the flexibility of these languages. You pay for that "flexibility" quite directly in lack of verifiability and of adequate performance. It's not a free lunch - if it was, we would all be using LISP anyway.
- brlewis 8y ago
  If those were the reasons for LISP's lack of popularity, then LISP would have been more popular than Python or PHP. What happened is that 1980s hardware was not ready for languages slower than C. C became the dominant language, and C-style syntax became the dominant syntax, with C++, Java and JavaScript following its lead. Eventually people adopted languages slower than C, but they didn't adopt paren-prefix notation.
  - kazinator 8y ago
    People used slower-than-C languages throughout the 1980's and onward: for instance BASIC-s (eventually Microsoft's Visual Basic starting in 1991), Ashton-Tate's dBase and its derivatives ("xBase").
- wutbrodo 8y ago
  Yes, I didn't say it was a free lunch. The entirety of my comments here are about how there are pros and cons to every language that manifest in different situations, and things like "ability to go into ugly technical debt for short-term speed boost" being a pro has nothing to do with the claim that it's an unalloyed good, but there are situations that play to its strengths and weaknesses. I hate to be rude, but I'm really not sure how you thought I hadn't already made this point if you had read the thread we're on. If anything, my original comment comes close to saying that static typing is superior, period (though the same caveats apply about different situations requiring different sets of strength and weaknesses). The obvious example here is that I unquestionably do my personal scripting in Python instead of C++, despite very much enjoying engineering jobs in the latter to those in the former. Different situations, different requirements.

scarface74 8y ago

I’m just started to get into Python and I generally don’t see the point of ORMs since they really don’t add much in my opinion. I’m really curious about Why you like the ORM for Python. The only ORMs I’ve ever found useful are those based on LINQ because LINQ makes any ORM (and whatever you call the Mongo LINQ driver) first class citizen and it integrates into the language.

wutbrodo 8y ago
I have the same rough opinion of ORMs in general and I've never had the occasion to examine it: it was the right choice for our org because there's no way in hell the engineers were going to learn to write good SQL when they could barely write good Python, especially when I'm far from a SQL expert. I was at the time capable of writing good SQL (presumably after a ramp up period), but I doubt my capability to teach it well without significant time investment. The ORM was a path of least resistance thing, providing a simple, easily-comprehensible interface in the language they were already writing. In the specific context of stuff-is-on-fire, production database changes (I'll reiterate, this place sucked), the fluency of the ORM and its seamlessness with our code was helpful. I don't know much about LINQ, but I gather that the syntax is declarative, which is a perhaps-minor speedbump that would nevertheless have made me less fluent in the specific above-described scenario. In the general case of engineering, LINQ looks like something I would far prefer. This isn't a criticism of your comment or anyone else's, but I have to say I'm amused by how all of my responses downthread of my comment are in defense of me being charitable towards more permissive languages (as I said, my bias probably swings solidly the other way, and if I never engineer in a permissive language again, I'll die happy). I kind of assumed it would go the other way, with HN jumping on my comment as elitist or something.
- scarface74 8y ago
  Every other ORM is bolted on. For instance if you write the following using LINQ: var x = from c in customers where c.Age > 65 && c.Sex == “male” select c; var results = x.ToList(): If customer represents an in memory list, it gets translated as regular old compiled code. If customer represents a sql database table - it gets translated to SQL and run on the database server. If customer represents a Mongo collection. It gets translated to a Mongo query. Of course you can do stuff like switch out what customer represents at runtime and it will be translated appropriately. You also get autocomplete help and compile time type checking. You can pass the where clause around: var expression = c.Age > 65; And pass it into a method.

zozbot123 8y ago

> Similarly, some pretty nifty stuff in libraries is possible due to the flexibility of these languages. You pay for that "flexibility" quite directly in lack of verifiability and of adequate performance. It's not a free lunch - if it was, we would all be using LISP anyway.

brlewis 8y ago
If those were the reasons for LISP's lack of popularity, then LISP would have been more popular than Python or PHP. What happened is that 1980s hardware was not ready for languages slower than C. C became the dominant language, and C-style syntax became the dominant syntax, with C++, Java and JavaScript following its lead. Eventually people adopted languages slower than C, but they didn't adopt paren-prefix notation.
- kazinator 8y ago
  People used slower-than-C languages throughout the 1980's and onward: for instance BASIC-s (eventually Microsoft's Visual Basic starting in 1991), Ashton-Tate's dBase and its derivatives ("xBase").
wutbrodo 8y ago
Yes, I didn't say it was a free lunch. The entirety of my comments here are about how there are pros and cons to every language that manifest in different situations, and things like "ability to go into ugly technical debt for short-term speed boost" being a pro has nothing to do with the claim that it's an unalloyed good, but there are situations that play to its strengths and weaknesses. I hate to be rude, but I'm really not sure how you thought I hadn't already made this point if you had read the thread we're on. If anything, my original comment comes close to saying that static typing is superior, period (though the same caveats apply about different situations requiring different sets of strength and weaknesses). The obvious example here is that I unquestionably do my personal scripting in Python instead of C++, despite very much enjoying engineering jobs in the latter to those in the former. Different situations, different requirements.