47 ms·

If lots of successful projects use what you consider the “worst” technology, perhaps the problem is with your perception rather than the technology?

devoply 9y ago
No the person has a point. Often the weakness of the tech stack are not known ahead of time. Or what is considered a weakness is not a weakness when the choices are initially made. Most developers if they had to do stuff over again would make different choices in one way or another. Also later in the game if you ever get there, when you have capital then certain problems that were caused by the choices made can be resolved a different way... as is the case here.
alsadi 9y ago
Those people believe that the right choice is assembly unless you can write directly in hex /s
- AnimalMuppet 9y ago
  Nonsense. Octal, not hex. (Not totally a joke. My mother wrote in octal before she got an assembler.)
- thechao 9y ago
  I was taught assembly at the job by an old assembly guru. His first statement to me was something along the lines of: "we'll use an assembler to start with, but it doesn't generate very good code; so, once you're comfortable, we'll hand assemble our machine code".
  - AlexCoventry 9y ago
    Was he just messing with you? What's a case where assembly is not isomorphic to machine code?
chc 9y ago
That seems like a pretty dodgy metric. Lots of successful construction projects used asbestos, but it is still widely considered a mistake.
- david-cako 9y ago
  The downside to using a certain tech stack is technical debt, not a health risk. Technical debt seems like a wise acquisition in moderation, especially for a startup that wants pictures and buttons on screens ASAP, and even more especially when everyone is realizing that it can rather easily be undone when/where it matters with type checker addons and FFI.
  - chc 9y ago
    That doesn't have anything to do with the question of whether "raw number of successful projects using it" is a good metric for how good something is. Lots of successful companies have made mistakes, and there are even mistakes that many companies in a field made simultaneously (e.g. the XML mania of the early 2000s is not fondly looked back on). I'm not commenting on the specific issue of whether Python creates good trade-offs, just that I think tallying successful companies is a poor measure of a programming language.
    - david-cako 9y ago
      Ah, I gotcha, that’s a good point. I still do believe that these decisions for dynamic languages that can later be contorted aren’t just a symptom, but I don’t have any way to prove it.

devoply 9y ago

No the person has a point. Often the weakness of the tech stack are not known ahead of time. Or what is considered a weakness is not a weakness when the choices are initially made. Most developers if they had to do stuff over again would make different choices in one way or another. Also later in the game if you ever get there, when you have capital then certain problems that were caused by the choices made can be resolved a different way... as is the case here.

alsadi 9y ago

Those people believe that the right choice is assembly unless you can write directly in hex /s

AnimalMuppet 9y ago
Nonsense. Octal, not hex. (Not totally a joke. My mother wrote in octal before she got an assembler.)
thechao 9y ago
I was taught assembly at the job by an old assembly guru. His first statement to me was something along the lines of: "we'll use an assembler to start with, but it doesn't generate very good code; so, once you're comfortable, we'll hand assemble our machine code".
- AlexCoventry 9y ago
  Was he just messing with you? What's a case where assembly is not isomorphic to machine code?

chc 9y ago

That seems like a pretty dodgy metric. Lots of successful construction projects used asbestos, but it is still widely considered a mistake.

david-cako 9y ago
The downside to using a certain tech stack is technical debt, not a health risk. Technical debt seems like a wise acquisition in moderation, especially for a startup that wants pictures and buttons on screens ASAP, and even more especially when everyone is realizing that it can rather easily be undone when/where it matters with type checker addons and FFI.
- chc 9y ago
  That doesn't have anything to do with the question of whether "raw number of successful projects using it" is a good metric for how good something is. Lots of successful companies have made mistakes, and there are even mistakes that many companies in a field made simultaneously (e.g. the XML mania of the early 2000s is not fondly looked back on). I'm not commenting on the specific issue of whether Python creates good trade-offs, just that I think tallying successful companies is a poor measure of a programming language.
  - david-cako 9y ago
    Ah, I gotcha, that’s a good point. I still do believe that these decisions for dynamic languages that can later be contorted aren’t just a symptom, but I don’t have any way to prove it.