4 ms·

Nitpick: jQuery exists to make the HTML DOM manageable, not JavaScipt the language. (There are libraries targeted at javascript the language, but you could make

by lerouxb 14y ago

Nitpick: jQuery exists to make the HTML DOM manageable, not JavaScipt the language. (There are libraries targeted at javascript the language, but you could make an argument that that's the point of all libraries for all languages...) I find jQuery more analogous to tools like configure and autoconf. (in that they aren't actually needed for "modern", standards compliant browsers.) As an example: there are already many lightweight drop-in replacements that assume a sane browser to begin with. CSS is remarkably hack-free and the resets are just to remove the default styling that browsers have built in. Obviously browsers need builtin styles otherwise all the old pre-css pages would stop working. And why are you calling programming languages and web servers hackish? How is nginx hackish and apache not? How is Objective C hackish and C++ not? Why stop inventing new languages at assembly, c or c++? Other than that I generally agree with the rest of your comment. I think if we ever get to some kind of technological singularity we'll almost certainly and just about by definition not understand how it works. And true/strong AI would definitely be a singularity. Even if we understood version 1 we would likely not be able to understand whatever it dreams up 5 seconds after we overclock it. And we will - moor's law and all that. ;)

jng 14y ago
I don't mean Nginx or Varnish are more hackish themselves than Apache. I could have said Apache instead of Nginx, but I think Back in the day, a "serious" application usually involved a large amount of quite homogeneous source code in a single language (or 2 or 3 different languages for different tasks: C/C++ for the main code/engine/logic, assembly for performance-sensitive code, and maybe some custom high-level script for high-level application logic). This was built usually on a single machine with a single build script, and resulted in some binary which could be deployed. Even early web apps were more akin to this model - Java apps, or even Perl apps. Nowadays, an "app" lives distributed among dozens of servers and client types. People describe what they have: "12 memcaches, 5 varnishes, 8 nginxes, 5 app servers with Ruby, 4 static content servers, and a MySQL master server with a fallback master and 5 slaves for reads. Separately, an Android app, an iPhone app and an HTML5 front-end." These systems started as a single app in a single box, and have "grown" for scalability, reliability and security, being patched up with different pieces of technology put together with often unreliable methods but fallback mechanisms that make it more resilient that if reliable methods were used but no fallback. It's not so important nowadays that the application code be clean, elegant, or failproof, but that measures are put in place so that the service will keep chugging along most of the time. And setting up the whole system from scratch involves a manual with probably hundreds of steps putting together haphazard technologies, installing different types of Linuxes and packages for each piece. And may even involve difficult-to-replicate steps, such as using an AMI to launch EC2 instances, where the engineer that created the original AMI doesn't even work here any more and recreating it from scratch would involve 20 packages, Googling for 5 of them as they're not available in normal repositories, 5 manual patches, two secret incantations and a tribal dance around the chair while singing and praying to arcane gods of long-forgotten package managers. {{Side-note: although it's not the main point, I'd definitely say Objective C is more hackish than C++. C++ has its own amount of weird stuff due to being built on top of C and its evolution with templates, etc... but the evolution of Objective C is done much more in the form of "patches". Even the original syntax takes advantage of awkward gaps in the syntax of C (@interface, @implementation, #import, [object msg:param]?). But it's even worse how new features are piled on top of old ones: properties, ARC 2.0, etc... it's distinctly noticeable when you just wouldn't feel comfortable teaching programmers new to Objective C how to use ARC, without learning the underlying memory management model first. In C++, people can learn "new" and "delete", and never hear about malloc()/free(), and there's no problem at all. Anyway, my point about hackishness was not referred to ObjC, but to how whole systems are engineered nowadays.}}
- lerouxb 14y ago
  You're basically describing the very nature of distributed systems :) We see many more of them nowadays because of the scale of some modern web apps / sites whereas in the 1990s the internet just wasn't that big or that complicated. Whether every app that ends up being that complicated actually needs to be like that is a different question. It also comes back to "don't reinvent the wheel" and "not invented here syndrome". You _could_ implement many of these things in your homogenous codebase or you could just reuse something that already works. I'm just saying there are serious and good counterarguments to the "large amount of quite homogenous source code written in a single language" approach. I agree with some of the details (like AMIs, EC2, different types and versions of linux, different package managers in the same system), but I think in general the things you think of as hacks aren't hacks at all and just the signs of progress. Or at least the nature of large, complex modern distributed systems. You basically described the term "agile development" and you're remembering a time many developers would rather forget with rather rose-tinted glasses. (I don't really know enough about objective-c to comment.)

by lerouxb 14y ago

jng 14y ago

I don't mean Nginx or Varnish are more hackish themselves than Apache. I could have said Apache instead of Nginx, but I think Back in the day, a "serious" application usually involved a large amount of quite homogeneous source code in a single language (or 2 or 3 different languages for different tasks: C/C++ for the main code/engine/logic, assembly for performance-sensitive code, and maybe some custom high-level script for high-level application logic). This was built usually on a single machine with a single build script, and resulted in some binary which could be deployed. Even early web apps were more akin to this model - Java apps, or even Perl apps. Nowadays, an "app" lives distributed among dozens of servers and client types. People describe what they have: "12 memcaches, 5 varnishes, 8 nginxes, 5 app servers with Ruby, 4 static content servers, and a MySQL master server with a fallback master and 5 slaves for reads. Separately, an Android app, an iPhone app and an HTML5 front-end." These systems started as a single app in a single box, and have "grown" for scalability, reliability and security, being patched up with different pieces of technology put together with often unreliable methods but fallback mechanisms that make it more resilient that if reliable methods were used but no fallback. It's not so important nowadays that the application code be clean, elegant, or failproof, but that measures are put in place so that the service will keep chugging along most of the time. And setting up the whole system from scratch involves a manual with probably hundreds of steps putting together haphazard technologies, installing different types of Linuxes and packages for each piece. And may even involve difficult-to-replicate steps, such as using an AMI to launch EC2 instances, where the engineer that created the original AMI doesn't even work here any more and recreating it from scratch would involve 20 packages, Googling for 5 of them as they're not available in normal repositories, 5 manual patches, two secret incantations and a tribal dance around the chair while singing and praying to arcane gods of long-forgotten package managers. {{Side-note: although it's not the main point, I'd definitely say Objective C is more hackish than C++. C++ has its own amount of weird stuff due to being built on top of C and its evolution with templates, etc... but the evolution of Objective C is done much more in the form of "patches". Even the original syntax takes advantage of awkward gaps in the syntax of C (@interface, @implementation, #import, [object msg:param]?). But it's even worse how new features are piled on top of old ones: properties, ARC 2.0, etc... it's distinctly noticeable when you just wouldn't feel comfortable teaching programmers new to Objective C how to use ARC, without learning the underlying memory management model first. In C++, people can learn "new" and "delete", and never hear about malloc()/free(), and there's no problem at all. Anyway, my point about hackishness was not referred to ObjC, but to how whole systems are engineered nowadays.}}

lerouxb 14y ago
You're basically describing the very nature of distributed systems :) We see many more of them nowadays because of the scale of some modern web apps / sites whereas in the 1990s the internet just wasn't that big or that complicated. Whether every app that ends up being that complicated actually needs to be like that is a different question. It also comes back to "don't reinvent the wheel" and "not invented here syndrome". You _could_ implement many of these things in your homogenous codebase or you could just reuse something that already works. I'm just saying there are serious and good counterarguments to the "large amount of quite homogenous source code written in a single language" approach. I agree with some of the details (like AMIs, EC2, different types and versions of linux, different package managers in the same system), but I think in general the things you think of as hacks aren't hacks at all and just the signs of progress. Or at least the nature of large, complex modern distributed systems. You basically described the term "agile development" and you're remembering a time many developers would rather forget with rather rose-tinted glasses. (I don't really know enough about objective-c to comment.)