A different take on superior technologies by someone some here may have heard about:
http://www.paulgraham.com/power.html
Don't Be Distracted by Superior Technology
21–30 of 68 posts
Re: Don't Be Distracted by Superior Technology
#22I’m not a programmer but have witnessed – and mediated - a lot of these arguments. Some are very esoteric while others are pretty practical. But some programmers forget that when you’re trying to implement a “large” project (relatively large user base and relatively long expected life), the programming language is just a tool. You can tinker forever with a technologically superior language – and enjoy the intellectua…
Or you could implement the project in the superior language in a reasonable amount of time.
Re: Don't Be Distracted by Superior Technology
#23There is a nice short story on this subject: "Superiority" by Arthur C. Clarke. You can find a summary and a full text link here: http://www.kareemamin.com/post/5060094569/3-lessons-for-star...
Re: Don't Be Distracted by Superior Technology
#24Meh, this is unfortunate advice because everyone tends to act this way too much . Almost everybody errs towards stable technologies; the exceptions are people with a genuine interest in the novel. They are disproportionately vocal so judging from the internet there's a lot of them, but in reality they're a minority. This makes sense psychologically. The cost of spending an extra day setting up a build system? It's ob…
> Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible.
Writing a JSON parser that parses my examples correctly is a couple hours at most, yes. Writing a JSON parser that I am confident is correct and robust and efficient takes somewhat longer.
Re: Don't Be Distracted by Superior Technology
#25I believe the pace of change has actually increased recently. As Hague himself has noted, we have a lot of computing power to throw around now. 30 years ago, serious usage of academic languages was still restricted to "big iron" environments; today you can expect any language to do some useful work even on a smartphone. As a result we can make "softerware" that benchmarks less well, but is massively cheaper to make a…
> There's a mindshare war going on there, but architecting against one language, one environment, and one toolchain is increasingly seen as the "old way". That old way is there for a reason: maintenance. If you write throw-away software (and most websites, especially the front end stuff are) then this is not a problem. But if you're supposed to support your creation for the next 15 years then having a stable toolset…
At this point, there are better technologies that are stable. My language of choice, for example:
Re: Don't Be Distracted by Superior Technology
#26I believe the pace of change has actually increased recently. As Hague himself has noted, we have a lot of computing power to throw around now. 30 years ago, serious usage of academic languages was still restricted to "big iron" environments; today you can expect any language to do some useful work even on a smartphone. As a result we can make "softerware" that benchmarks less well, but is massively cheaper to make a…
> There's a mindshare war going on there, but architecting against one language, one environment, and one toolchain is increasingly seen as the "old way". That old way is there for a reason: maintenance. If you write throw-away software (and most websites, especially the front end stuff are) then this is not a problem. But if you're supposed to support your creation for the next 15 years then having a stable toolset…
No, that's still making the assumption that all worthwhile solutions are balls of mud, leading to "freeze it in time" as the only sane option for preservation. That's cultural, not inherent to the technology.
If every part of the stack is tiny and connected via common, documented protocols you have ample room for maintenance. That's easily validated by the Internet as a whole (and not the Web, which was burdened by its early design). A present-day "throw-away" that can do more than in the past is, more likely than not, leveraging a bigger and more decomposed software ecosystem, where bits of infrastructure can get remixed more readily. Pooh-poohing the results by saying "they solved a trivial problem" dismisses this underlying trend - tools and services that are currently "weekend hack" or "prototype only" have a habit of turning into tomorrow's "production-grade" if they gain substantial adoption.
There's no particular reason we can't achieve Internet-scale maintainability for all problems, other than it taking time to build protocols of the right size/complexity for every problem domain.
Re: Don't Be Distracted by Superior Technology
#27Meh, this is unfortunate advice because everyone tends to act this way too much . Almost everybody errs towards stable technologies; the exceptions are people with a genuine interest in the novel. They are disproportionately vocal so judging from the internet there's a lot of them, but in reality they're a minority. This makes sense psychologically. The cost of spending an extra day setting up a build system? It's ob…
> Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible. Writing a JSON parser that parses my examples correctly is a couple hours at most , yes. Writing a JSON parser that I am confident is correct and robust and efficient takes somewhat longer.
It's really more of a case of porting a JSON parser because many working examples of JSON parsers already exist, as do complete sets of test data that your parser must be able to handle. There's really not a lot of original thought that has to go into recreating something that's already well-established elsewhere.
Re: Don't Be Distracted by Superior Technology
#28Meh, this is unfortunate advice because everyone tends to act this way too much . Almost everybody errs towards stable technologies; the exceptions are people with a genuine interest in the novel. They are disproportionately vocal so judging from the internet there's a lot of them, but in reality they're a minority. This makes sense psychologically. The cost of spending an extra day setting up a build system? It's ob…
> Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible. Writing a JSON parser that parses my examples correctly is a couple hours at most , yes. Writing a JSON parser that I am confident is correct and robust and efficient takes somewhat longer.
Haskell, and BoS, i think, are both special cases. First, Haskell is actually pretty old. There are changes, of course, but the core language is '98. IIRC, Brian O'Sullivan wrote a high performance parsing library, attoparsec.
In general, I think i agree with the article. In this specific case, it's a fantastic example of leveraging your strengths to do something amazing.
Re: Don't Be Distracted by Superior Technology
#29Earlier quoted context omitted.
> Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible. Writing a JSON parser that parses my examples correctly is a couple hours at most , yes. Writing a JSON parser that I am confident is correct and robust and efficient takes somewhat longer.
It's really more of a case of porting a JSON parser because many working examples of JSON parsers already exist, as do complete sets of test data that your parser must be able to handle. There's really not a lot of original thought that has to go into recreating something that's already well-established elsewhere.
Fair point. There can still be a lot of work to ensure robustness and efficiency in the new setting (especially so if the execution model is particularly different).
Re: Don't Be Distracted by Superior Technology
#30I’m not a programmer but have witnessed – and mediated - a lot of these arguments. Some are very esoteric while others are pretty practical. But some programmers forget that when you’re trying to implement a “large” project (relatively large user base and relatively long expected life), the programming language is just a tool. You can tinker forever with a technologically superior language – and enjoy the intellectua…
"Or you can settle for a less sophisticated language and implement your project in a reasonable amount of time, though not as elegantly as you might like."
And be stuck maintaining horribly inelegant 10-year-old systems written in a "stable" language that was obsolete 5 years ago. A system where pushing a change in one module breaks 3 others.
But hey, "worse is better" right?