5 ms·

> I think programmers tend to underestimate the difficulties involved with becoming a good programmer because once you're good, you only see the even steeper le

> I think programmers tend to underestimate the difficulties involved with becoming a good programmer because once you're good, you only see the even steeper learning curve ahead of you. But that is no definition of bubble. Bubble, at a very basic level, means there is a lot of capital flowing within, it has little to do with whether how difficult your job is.

Pamar 8y ago
This is... debatable. I was around in 1985 and if I had proposed using "an eventually consistent schemaless DB" to tackle a bank or a manufacturing project I would have been laughed out of the room. And not because it sounded too good to be true, mind you...
- ummonk 8y ago
  Does anyone do that, at least on the software side? Obviously there are consistency issues with e.g. non-instantaneous bank teller actions, but those are human inconsistencies, not software inconsistencies..
  - Pamar 8y ago
    What I mean is that some of the powerful components we can leverage today solve problems that did not exist in 1985, so having these available then would not really help. I mean: what would you use Node.js for - in 1985 - even assuming you had access to a system to develop and test stuff made with it?
    - sedachv 8y ago
      > I mean: what would you use Node.js for - in 1985 In 1985, your hypothetical bank would be running VMS, which had asynchronous IO system calls as the default. There was no need to "invent" something like Node.js.
- woolvalley 8y ago
  Funny thing is, that is what ACH and many other banking systems are today, or at least back then. "Reconciliation" can take days.
- sedachv 8y ago
  > I was around in 1985 and if I had proposed using "an eventually consistent schemaless DB" to tackle a bank or a manufacturing project I would have been laughed out of the room. Medical record systems were running on MUMPS (schemaless) and being eventually consistent (records were keyed in from paper forms) long before 1985.

Pamar 8y ago

This is... debatable. I was around in 1985 and if I had proposed using "an eventually consistent schemaless DB" to tackle a bank or a manufacturing project I would have been laughed out of the room. And not because it sounded too good to be true, mind you...

ummonk 8y ago
Does anyone do that, at least on the software side? Obviously there are consistency issues with e.g. non-instantaneous bank teller actions, but those are human inconsistencies, not software inconsistencies..
- Pamar 8y ago
  What I mean is that some of the powerful components we can leverage today solve problems that did not exist in 1985, so having these available then would not really help. I mean: what would you use Node.js for - in 1985 - even assuming you had access to a system to develop and test stuff made with it?
  - sedachv 8y ago
    > I mean: what would you use Node.js for - in 1985 In 1985, your hypothetical bank would be running VMS, which had asynchronous IO system calls as the default. There was no need to "invent" something like Node.js.
woolvalley 8y ago
Funny thing is, that is what ACH and many other banking systems are today, or at least back then. "Reconciliation" can take days.
sedachv 8y ago
> I was around in 1985 and if I had proposed using "an eventually consistent schemaless DB" to tackle a bank or a manufacturing project I would have been laughed out of the room. Medical record systems were running on MUMPS (schemaless) and being eventually consistent (records were keyed in from paper forms) long before 1985.