4 ms·

If the parent is sarcasm, please disregard my reply. > The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done

If the parent is sarcasm, please disregard my reply. > The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before. Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share. I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone. > This is the drag&drop and copy-paste as an abstraction VB shit era. And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful. > People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles. What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level. > Security was abysmal - you didn't even have process isolation on OS-es. Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse. > Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics. The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things. Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).

rubber_duck 10y ago
Like I've said the stuff that hasn't changed much is the CS, the actual engineering part has nothing to do with what we do today. 20 years ago the net was nowhere nearly as ubiquitous, hardware was incomparably slow, the bottlenecks were different - the focus shifted from single computer/mainframes/shared memory models -> distributed computing. When I say copy paste in visual basic I'm talking about professional programmers that couldn't even abstract stuff in to functions but would copy paste shit all over the code - not copy-pasting from other sources. As much as people like to bitch about our industry we have heavily increased engineering standard, if you don't use source control these days you get laughed at, if you don't use automated testing you're an amateur, even junior programmers know about patterns and nobody copy-pastes code over their code base - stuff like this was the exception back then not the norm as it is now. You can say MVC was invented in the 80s or w/e but up until maybe 10 years ago the internet was full of tutorials/guides on how to do web coding by interpolating PHP inside of your HTML, using string concatenation to build SQL queries and such nonsense. Sure top 10% never did that but the vast majority of programmers did and the broader industry has improved significantly since then, in no small part thanks to the frameworks that constrain the bad developers on to the "good path".
- eropple 10y ago
  If you don't use source control these days, you're below average. If you don't use automated testing, you are probably average. Plenty of junior programmers know nothing about patterns except how to cargo-cult them. Plenty of people copy-paste code everywhere. I'm curious how long you've been doing this stuff, because this sounds like neophilia.
- optionalparens 10y ago
  We don't really have many true standards, just pockets of consensus on best practices and collections of so-called standards that are quite often ignored. Thanks to better communication, I think it's safe to agree that these practices are more widespread. As a result, yes, quality for certain groups has definitely increased. I think you underestimate the fact that a large number of people actually do not follow these practices, even those that know better. Further, it's hard to make statements about software quality, especially with so many moving variables like the increase in the total amount of people in the industry and lower barriers to entry. Regarding best practices, I am sure many people have stories about asking questions in interviews about a company's software development, only to be told, "Well we'd love to do X, but we just don't have the resources or time, so we do Y." Even people who know better do otherwise in addition to those that are ignorant. I think at a conceptual level, many things have not changed. There have always been sets of new ideas and practices that people adopted, many times blindly. These are of course a mixed bag, but many so-called "best practices" are often abandoned later - fads are the norm, and while that's sometimes OK, it does not always result in "better" as much as "different." I think some people fail to realize that in the moment, it's all happened before, and all will happen again. We both learn from our past mistakes with new trends and repeat those mistakes. MVC and frameworks are actually interesting examples. I don't want to get too into individual tech discussions, but I've personally seen people handcuff themselves trying to religiously implement things such as MVC and actually failing because of a pattern like that since they were distracted from solving the problems properly. Adopting a pattern or framework does not automatically produce better code and can even lead you the opposite way. It's hard to say if things like this are a win for all so much as if they are simply a good fit for certain problems, and therein lies the challenge and one that hasn't become easier. The golden hammer or wrong tool will forever be problems. Frameworks often are oversold and are not standards. In fact I've found that for many projects I have actually had to abandon a particular framework long-term because it was just getting in the way for various reasons - performance, maintainability, velocity of change, conceptual failings, zealotry, etc. Frameworks can derail "bad" developers as you call them just as much as good ones. Frameworks often explode if you don't do things the "one true way" and "bad" developers can be argued to be prone to that just as much as everyone else, and simply adhering to these rules still doesn't always produce better software. There have always been frameworks in one shape or form, but they didn't always have names, sometimes they were just the language or tool imposing its constraints, sometimes for the best, sometimes the worst. As a counterpoint, I've actually found working in various languages like Clojure, Lisp, and Racket that tend to value composition of tools and functions over frameworks more productive, however I would never apply this to all projects and situations. I see what you're getting overall at and on some level I agree. I was around in the 80s, and I don't want to go back to that. At the same time, for all the old problems solved, I see new ones that arise along with other things that were never problems coming to haunt us. It sounds like your experience is very compartmentalized to web development and you're projecting those views on to both the past and present. People are people, and no time, technologies, or tools will fix that, just deal you different cards.

rubber_duck 10y ago

Like I've said the stuff that hasn't changed much is the CS, the actual engineering part has nothing to do with what we do today. 20 years ago the net was nowhere nearly as ubiquitous, hardware was incomparably slow, the bottlenecks were different - the focus shifted from single computer/mainframes/shared memory models -> distributed computing. When I say copy paste in visual basic I'm talking about professional programmers that couldn't even abstract stuff in to functions but would copy paste shit all over the code - not copy-pasting from other sources. As much as people like to bitch about our industry we have heavily increased engineering standard, if you don't use source control these days you get laughed at, if you don't use automated testing you're an amateur, even junior programmers know about patterns and nobody copy-pastes code over their code base - stuff like this was the exception back then not the norm as it is now. You can say MVC was invented in the 80s or w/e but up until maybe 10 years ago the internet was full of tutorials/guides on how to do web coding by interpolating PHP inside of your HTML, using string concatenation to build SQL queries and such nonsense. Sure top 10% never did that but the vast majority of programmers did and the broader industry has improved significantly since then, in no small part thanks to the frameworks that constrain the bad developers on to the "good path".

eropple 10y ago
If you don't use source control these days, you're below average. If you don't use automated testing, you are probably average. Plenty of junior programmers know nothing about patterns except how to cargo-cult them. Plenty of people copy-paste code everywhere. I'm curious how long you've been doing this stuff, because this sounds like neophilia.
optionalparens 10y ago
We don't really have many true standards, just pockets of consensus on best practices and collections of so-called standards that are quite often ignored. Thanks to better communication, I think it's safe to agree that these practices are more widespread. As a result, yes, quality for certain groups has definitely increased. I think you underestimate the fact that a large number of people actually do not follow these practices, even those that know better. Further, it's hard to make statements about software quality, especially with so many moving variables like the increase in the total amount of people in the industry and lower barriers to entry. Regarding best practices, I am sure many people have stories about asking questions in interviews about a company's software development, only to be told, "Well we'd love to do X, but we just don't have the resources or time, so we do Y." Even people who know better do otherwise in addition to those that are ignorant. I think at a conceptual level, many things have not changed. There have always been sets of new ideas and practices that people adopted, many times blindly. These are of course a mixed bag, but many so-called "best practices" are often abandoned later - fads are the norm, and while that's sometimes OK, it does not always result in "better" as much as "different." I think some people fail to realize that in the moment, it's all happened before, and all will happen again. We both learn from our past mistakes with new trends and repeat those mistakes. MVC and frameworks are actually interesting examples. I don't want to get too into individual tech discussions, but I've personally seen people handcuff themselves trying to religiously implement things such as MVC and actually failing because of a pattern like that since they were distracted from solving the problems properly. Adopting a pattern or framework does not automatically produce better code and can even lead you the opposite way. It's hard to say if things like this are a win for all so much as if they are simply a good fit for certain problems, and therein lies the challenge and one that hasn't become easier. The golden hammer or wrong tool will forever be problems. Frameworks often are oversold and are not standards. In fact I've found that for many projects I have actually had to abandon a particular framework long-term because it was just getting in the way for various reasons - performance, maintainability, velocity of change, conceptual failings, zealotry, etc. Frameworks can derail "bad" developers as you call them just as much as good ones. Frameworks often explode if you don't do things the "one true way" and "bad" developers can be argued to be prone to that just as much as everyone else, and simply adhering to these rules still doesn't always produce better software. There have always been frameworks in one shape or form, but they didn't always have names, sometimes they were just the language or tool imposing its constraints, sometimes for the best, sometimes the worst. As a counterpoint, I've actually found working in various languages like Clojure, Lisp, and Racket that tend to value composition of tools and functions over frameworks more productive, however I would never apply this to all projects and situations. I see what you're getting overall at and on some level I agree. I was around in the 80s, and I don't want to go back to that. At the same time, for all the old problems solved, I see new ones that arise along with other things that were never problems coming to haunt us. It sounds like your experience is very compartmentalized to web development and you're projecting those views on to both the past and present. People are people, and no time, technologies, or tools will fix that, just deal you different cards.