5 ms·

I'm not sure that's true at all. A lot of us older developers look at the tools we used in the 1970s, 1980s and 1990s, and we can't help but notice how much bet

I'm not sure that's true at all. A lot of us older developers look at the tools we used in the 1970s, 1980s and 1990s, and we can't help but notice how much better they are, even today, than many of the most-hyped tools these days. I feel sorry for many of the younger developers today who only know of JavaScript, PHP, NoSQL and web development. They don't know what they're missing out on, nor do they truly know how inferior their tools are. And when it comes to getting serious work done, we still use C, C++ and Fortran today. Yes, they've advanced in many ways over time, but I think they just go to show how much better many technologies were in years past. Even modern tools just can't compete with them.

mamcx 13y ago
I still think foxpro/visual foxpro and more recently delphi was the most accesible dev environment. I still have not found the easy and power of fox to do data task and the RAD way of delphi in any tool I have tried...
mistercow 13y ago
>NoSQL I don't feel sorry for anyone who hasn't had to work with relational databases.
- prodigal_erik 13y ago
  I feel kind of sorry for anyone using a database with no schema enforcement, who has yet to learn why hope is not a strategy for maintaining its integrity over time. I've seen Notes documents decay to nonsensical states the app can't handle at all within five years.
  - mistercow 13y ago
    I haven't actually used NoSQL in a project, so I can't speak to whether those disadvantages are worth the trade off or not in practice. What I can say is that it is a trade off to use a relational database. The problem with relational databases is that constructing queries for anything but the simplest operations is incredibly counterintuitive, and easy to screw up in subtle ways. Then, the data you get out is usually nothing like the actual structure you need, so you have to process it and squish it into the shape you want. The common results I've seen of this are 1) programmers writing loops to execute simple queries that they can understand, and 2) programmers writing insanely inefficient or totally broken complex queries. And that's assuming that the database was designed correctly (or even sanely) in the first place. And yes, you can use an ORM, but then it becomes even more questionable whether you're getting any sort of benefit over NoSQL. The crux of the problem is that the standard-issue persistence mechanism for web development is something that superficially appears to be accessible via ordinary programming knowledge, but actually turns out to have been developed by a long lost Martian colony whose technological evolution followed a radically different path from our own. MySQL is not something you should jump into without having at least read a book on relational database design, and that's a step that many programmers clearly do not take. Current NoSQL solutions clearly have their problems too, but from what I can tell, they don't seem to be insurmountable ones. And at least it's a step in a new direction, even if it's not quite the right one. Bad database design and use is a plague, and it's pretty clear by now that education alone isn't a practical solution.
pjmlp 13y ago
I miss the compile times, native compilers and RAD abilities for strong type languages like Turbo Pascal and Delphi that were already available in 16 bit environments. Funny to see younger developers rediscovering this type of tooling that was killed by C and VM environments.

mamcx 13y ago

I still think foxpro/visual foxpro and more recently delphi was the most accesible dev environment. I still have not found the easy and power of fox to do data task and the RAD way of delphi in any tool I have tried...

mistercow 13y ago

>NoSQL I don't feel sorry for anyone who hasn't had to work with relational databases.

prodigal_erik 13y ago
I feel kind of sorry for anyone using a database with no schema enforcement, who has yet to learn why hope is not a strategy for maintaining its integrity over time. I've seen Notes documents decay to nonsensical states the app can't handle at all within five years.
- mistercow 13y ago
  I haven't actually used NoSQL in a project, so I can't speak to whether those disadvantages are worth the trade off or not in practice. What I can say is that it is a trade off to use a relational database. The problem with relational databases is that constructing queries for anything but the simplest operations is incredibly counterintuitive, and easy to screw up in subtle ways. Then, the data you get out is usually nothing like the actual structure you need, so you have to process it and squish it into the shape you want. The common results I've seen of this are 1) programmers writing loops to execute simple queries that they can understand, and 2) programmers writing insanely inefficient or totally broken complex queries. And that's assuming that the database was designed correctly (or even sanely) in the first place. And yes, you can use an ORM, but then it becomes even more questionable whether you're getting any sort of benefit over NoSQL. The crux of the problem is that the standard-issue persistence mechanism for web development is something that superficially appears to be accessible via ordinary programming knowledge, but actually turns out to have been developed by a long lost Martian colony whose technological evolution followed a radically different path from our own. MySQL is not something you should jump into without having at least read a book on relational database design, and that's a step that many programmers clearly do not take. Current NoSQL solutions clearly have their problems too, but from what I can tell, they don't seem to be insurmountable ones. And at least it's a step in a new direction, even if it's not quite the right one. Bad database design and use is a plague, and it's pretty clear by now that education alone isn't a practical solution.

pjmlp 13y ago

I miss the compile times, native compilers and RAD abilities for strong type languages like Turbo Pascal and Delphi that were already available in 16 bit environments. Funny to see younger developers rediscovering this type of tooling that was killed by C and VM environments.