7 ms·

The strict Pragma is a Cultural Marker

75 points by Mithaldu 13y ago

marquis 13y ago
Perl was my first language that I really engaged with, it started my career. Why did it fall out of favour? (I left web development to write applications/C, then returned some years later to write APIs but everyone had stopped using it).
- InclinedPlane 13y ago
  Perl has stagnated, it's as simple as that. There are so many alternatives out there that have picked up where Perl left off or gone in new directions and covered some of the same ground that the competitive value of Perl has diminished over time. I consider Ruby, for example, a more evolved Perl in a lot of ways. Perl used to be the go to language for scripting and automation (practically what it was designed for) but now that niche is also filled with Python, Ruby, node, power shell, and improved automation tools like puppet, chef, or ansible. Perl also used to be the go to language for dynamic web applications but it fell behind as other languages gained ground and especially as sophisticated frameworks like rails put Perl development to more and more of a comparative disadvantage.
  - chromatic 13y ago
    I consider Ruby, for example, a more evolved Perl in a lot of ways. Hopefully not in strength of module system, automated testing, extension mechanisms that aren't monkeypatching, quality of core development practices, metaprogramming (if you count Moose or p5-MOP), documentation, lexical scoping, or Unicode support.
- daemonburrito 13y ago
  This is just a personal opinion, but I also wrote Perl (back in the 90s), and I think that TIMTOWTDI was the reason that it fell out of favor. TIMTOWTDI makes it hard to share code, even between masters. I believe it's the source of the "Perl is unreadable" meme. Because everyone is capable of defining their own personal dialect of Perl, no solid, common subset emerged. Compare with the Zen of Python: "There should be one – and preferably only one – obvious way to do it." In Python, it's generally very easy for two similarly-skilled Python hackers to share code. It looks like a Wikipedia editor shares this view: http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_...
  - slashdotaccount 13y ago
    > no solid, common subset emerged That's wrong. This common subset converged through consensus and finds expression in e.g. the Modern Perl movement, the module collection Task::Kensho and the updated motto "There is more than one way to do it, but sometimes consistency is not a bad thing either".
    - smacktoward 13y ago
      All of those things emerged long after Perl had ceded its position in the language marketplace. It's great that Perl has them now, but the process of working them out took a loooong time.
      - chromatic 13y ago
        Isn't that the case with every New Jersey language?
  - riffraff 13y ago
    ruby flourished while perl was going down, even though it also shares TIMTOWTDI.
    - tl 13y ago
      Ruby flourished largely due to rails which ends up being pretty opinionated about how to do things.
    - bunderbunder 13y ago
      Yup. Which is why I'm personally a bit uneasy about Ruby's long-term future. It's attractive for the same reasons that Perl was attractive, but that means it also invites some of the same issues that Perl experienced. Wild speculation follows: There's always a need for a solid "just get shit done" language, but maybe any good language in this space is doomed to die by its own success. Crufty, hard to maintain code accumulates over time, because quickly banging out code you don't expect to still be maintaining in 10 years is the whole point. As that cruft accumulates, people start noticing it and inevitably blame the language. That leads to casting about for the next "just get shit done" language, and the cycle repeats.
- slashdotaccount 13y ago
  It didn't fall out of favour, Perl usage is growing every year. The "market" expanded as a whole, admitting newer languages. http://blog.timbunce.org/2008/03/08/perl-myths/ http://blog.timbunce.org/2008/03/08/perl-myths/
  - kbenson 13y ago
    While I sympathize with that position, I think it glosses over some important implications. When the market expands rapidly, but you share does not, you are either missing new entrants, losing existing adherents, or some combination thereof. Most importantly, your relevance is shrinking even if your market share is not. That said, it is an important morale booster to know it's not actually shrinking. Note: You and your in this case is meant generally, as it most definitely includes me.
    - chromatic 13y ago
      When the market expands rapidly, but you share does not... My collection of Programming Books Which I Will Discard Before I Ever Move Them Again includes a book about CGI programming with the Korn shell. I am not making this up. As you well know, back in the day when CGI was magic and server-side includes were amazing, there weren't a lot of options for server side programming. You had C, if you were a Unixy systems programmer and didn't mind doing string processing in C. You had Tcl, if you wanted to go the AOLserver route. You had whatever shell script you wanted, if you wanted to pipe and stream together Unixy commands. After a time, you even had server-side JavaScript, if you spent a lot of money on Netscape server products. You also had Perl, which ran on just about every Unix under the sun and behaved the same way pretty much everywhere. Even if you couldn't rely on one Unix utility behaving the same on every Unix variant (unless you somehow managed to get the GNU tools installed), you could rely on Perl being just about everywhere. Better yet, it had a fair library of code being developed and published because people were sharing it. In the early days, you might have to use a Perl fork to connect to an Oracle or a Sybase installation, but you even had that option. (Yeah, you could do that in C too, but that would be borrowing pain far beyond string handling in C.) It's pretty easy to see why Perl ended up with a lot of that market. It fit that niche which hadn't previously existed, and there wasn't much competition. (Korn shell. Korn. Shell.) The market expanded rapidly. Then the competition expanded rapidly because the market expanded rapidly. It's innumerate to suggest that the relative position of market share will remain the same or even grow when the market grows so rapidly and so much competition appears.
- smacktoward 13y ago
  It was Perl 6. As soon as it became clear that the move from 5 to 6 was going to be discontinuous, if you wanted to be a Perl developer you had to decide if that meant being a Perl 5 developer or a Perl 6 developer. Being a Perl 6 developer was the clearly marked path to The Future, but Perl 6 was years away from being ready to use in production environments, and it never seemed to get any closer. Perl 5 was practical for real-world use, but choosing to be a Perl 5 developer meant worrying that you were investing time and energy learning skills that were already marked as obsolete and writing code that would end up having to be re-written. That kind of uncertainty is fatal to a language. Why put up with it when there's so many other languages out there with clear upgrade paths? Especially when the upgrade path for the one you're using now appears pretty similar to learning a new language anyway? So developers drifted away from Perl to other languages, and that, as they say, was that.
  - baudehlo 13y ago
    I was once one of the most prolific authors on CPAN, and this, along with my answer above about lack of performance, drove me away. Perl(5) just needed classes and clean up a few bits of historic cruft (like the need to end modules in "1;", indirect object syntax, etc) and it could have been an awesome language. Perl6 decided to throw the baby out with the bathwater.
  - slashdotaccount 13y ago
    Ah, that old chestnut again. The argument falls down when we see what really happened: Perl 6 had and continues to have a huge positive influence on Perl 5, the future belongs to both as there turned out to be no discontinuous move, and Perl 5 stays up-to-date.
    - Peaker 13y ago
      Even if it is only the way things are perceived, and not the actual truth - it can still explain the decay of the community.
      - draegtun 13y ago
- baudehlo 13y ago
  Along with the other excellent answers, one thing Perl never got was a faster runtime. This drove me into the arms of V8 (via Node.js). Ruby got jRuby and Rubinius, PHP got the excellent work Facebook did, Python got PyPy, and many cool languages started to appear on the JVM. Perl got stuck with /usr/bin/perl. Having said that, the internals of Perl continue to improve in the current interpreter, and there's some long standing amazing work such as the incredible performance of the DBI drivers (look at the techempower benchmarks to see how well Perl shines even versus Node.js when it comes to database access). I still use Perl for small scripts, but I'm just not building anything big in it these days. Perl6 was a huge lost opportunity, and a massive failure in vision and leadership.
- tenfingers 13y ago
  Programming languages are often too associated with popularity, and the "big products" which have been produced with it in the last few years. Being "old", especially in the startup world, is already a big negative. This has been applied to the numerous proprietary languages which were popular during the 90' for web development, and it will happen again to the current popular choices. Perl by itself has very little to do with it. I've seen "worse" languages become popular and fade away.
kanatohodets 13y ago
Interesting to think about the sorts of cultural markers that other languages have. Maybe this is just another way of saying 'code smell', but there must be similar elements for JS/Ruby/Python (for example) where it the code isn't strictly 'wrong' (or even debatably wrong), but is still clearly indicative of a particular cultural approach towards coding in that language. Like overriding Array.prototype.push in JS - it might be just fine, but I tend to pause and re-evaluate my attitude towards the code when I see that going on, because it's a very different approach to coding in JS than I personally use.
- mattmanser 13y ago
  I tend to see much clearer indicators in JavaScript code. Global variables? Lots of functions outside any closure? Old skool js coder ahead. You can also tell javascript only programmers a mile off. Anonymous functions everywhere? Functions have multiple concerns? Use 'var aFunction = function()'? Mono linguist and spaghetti code ahead.
  - baudehlo 13y ago
    A lot more JS coders could benefit from adding "use strict" to their code too. It's frankly amazing it isn't used more.
    - Mithaldu 13y ago
      Honestly, in practive it falls short and doesn't do nearly enough. :(
      - baudehlo 13y ago
        True. It does far too little at compile time. I don't understand why. Maybe we need a "use compile strict" ;)
  - losethos 13y ago
    My compiler is better than C/C++. If you do not have arguments, you do not need parenthesis on function calls. You are a nigger. I wrote a compiler. If you were not a nigger, I might have thought you found my "PAREN_WARN" compiler option. I have different precedence rules for my language, so to keep everybody on their toes, I give a warning if you have extra parens.
darbelo 13y ago
Worth reading even if you aren't a perl guy. Every language has this type of 'cultural markers' that set your expectations for a codebase by skimming a few files or just the project structure. On that first dive into someone else's code[1], this markers are invaluable, they are the first cue into the author's mindset and background. They are a signal for future maintainers or collaborators. It's like stepping off the plane and hearing people around you speak with your own regional accent. Even if you've never been here before, now you know some of your knowledge still applies. [1] Rule of thumb, if you haven't touched your own code for a long time, think of it as being written by someone else. You are not the same person you were when you wrote it.
- Zancarius 13y ago
  > Rule of thumb, if you haven't touched your own code for a long time, think of it as being written by someone else. You are not the same person you were when you wrote it. This is really insightful, most especially the part I italicized. I can think of a few particularly embarrassing moments when I've dug through old code of mine and immediately thought "What kind of idiot wrote this crap?" followed by a brief moment of horror when the realization sets in that the idiot was me. :) I think it would also make a fantastic addendum to this [1] discussion (and the article to which it is attached), especially since many new programmers often don't think much of code maintenance. Usually it's comprised of "I (or someone else) will eventually rewrite this." Then it enters production. [1] https://news.ycombinator.com/item?id=6789504 https://news.ycombinator.com/item?id=6789504
  - hsmyers 13y ago
    Can't step in the same river twice is true in all domains, not just software. Admittedly with some languages it is worse than others, assembler and APL come to mind but same truth still applies.
  - Groxx 13y ago
    I've come to (try to) document / code like I assume the next person reading it will be both insane and stupid. Usually that's me. Usually it was worth the extra effort :) And at the very least it's a measure of progress, as I'm no longer that insane and stupid.
leokun 13y ago
I just don't understand why anyone developing a language would think dynamic scope would be a good idea.
- geocar 13y ago
  Richard Stallman gave an excellent use and rationale for dynamic scope in the EMACS manual: http://www.gnu.org/software/emacs/emacs-paper.html#SEC17 http://www.gnu.org/software/emacs/emacs-paper.html#SEC17 One of my favourite things about perl and CL is the ability to have lexical (my/let) and dynamic (local/special) scope in the same program depending on what is clearer. In fact, it comes up often enough that programming in a language lacking dynamic scope (e.g. basic, JavaScript, or python) feels limiting sometimes, and I end up emulating it (settings+extend, observables, etc).
  - jlgreco 13y ago
    That rationale may be a bit revisionist, here is Olin Shivers' take on RMS's justification for elisp's dynamic scoping: "Some context: Common Lisp did not exist (the effort was just getting underway). MIT Scheme did not exist. Scheme was a couple of AI Lab tech reports and a master's thesis. We're talking the tiniest seed crystal imaginable, here. There was immense experience in the lisp community on optimising compiled implementations of dynamically-scoped languages -- this, to such an extent, that it was a widely held opinion at the time that "lexical scope is interesting, theoretically, but it's inefficient to implement; dynamic scope is the fast choice." I'm not kidding. To name two examples, I heard this, on different occasions, from Richard Stallman (designer & implementor of emacs lisp) and Richard Fateman (prof. at Berkeley, and the principal force behind franz lisp, undoubtedly the most important lisp implementation built in the early Vax era -- important because it was delivered and it worked). I asked RMS when he was implementing emacs lisp why it was dynamically scoped and his exact reply was that lexical scope was too inefficient. So my point here is that even to people who were experts in the area of lisp implementation, in 1982 (and for years afterward, actually), Scheme was a radical, not-at-all-accepted notion. And outside the Lisp/AI community... well, languages with GC were definitely not acceptable. (Contrast with the perl & Java era in which we live. It is no exaggeration, thanks to perl, to say in 2001 that billions of dollars of services have been rolled out to the world on top of GC'd languages.)" http://www.paulgraham.com/thist.html http://www.paulgraham.com/thist.html (emphasis not my own) That whole page is a good read, particularly if you are a fan of Shivers' writing style.
bane 13y ago
I find that when I use 'struct' in my Perl, I have a psychological mind shift in how I write the code. Instead of hacking together some code, I start to take it more seriously, and start to care about everything from what I choose as my variable names to the overall sructure of the code. I start to care about maintainability. To be honest, I end up eliminating lots of clover Perl idioms and make the code much more 'C' and Java like, explicitly declaring most of my variables at the top of functions and making them verbose and consistent. I start to document everything and write lots of comments explaining what I'm doing. It really doesn't add much overhead to the overall development to be honest. I think as if I have to give the code to somebody else, even if that other person is me in the far future. It's served me well, I've returned to old pieces of code I wrote years before (even multiple 10s of KLOCS) and after a couple read through was able to get to work without much fuss. Fitting in with Larry's idea of programming languages as real languages, it's as if I've code-switched from a colloquial language to the kind of formal language I might use when giving a presentation.
- Mithaldu 13y ago
  > explicitly declaring most of my variables at the top of functions While i largely agree with the rest of your code, that one bit i can't generally agree with. If you take care to keep all your functions below 15 or so lines, i.e. such that they fit on one screen, then that's fine. As soon as you write bigger functions you end up impacting your code quality in two ways: - readability and refactorability go down, because coders after you have to read more code to see the context of a variable - the chance of bugs goes up because you're more tempted to reuse a predeclared variable in a loop, instead of redeclaring it at every start of a loop; or more insidiously, reuse the same variable as the counter in multiple loops So please: Declare your variables as late as humanly possible, optimally only directly before they're used.
  - bane 13y ago
    I don't disagree with your points at all. Short life variables I do tend to declare later in the code. But most of the major state variables (especially the ones that get returned, or important data structures I want to keep track of in the code flow) I stick at the top with comments and explanations of what the variable is and why it exists.
jfb 13y ago
As the child of anthropologists, I think there's a lot of room for cultural analysis of technologies. Languages, for instance, have cultures as well as affordances, and a careful comparative analysis would be really interesting.

75 points by Mithaldu 13y ago

Perl was my first language that I really engaged with, it started my career. Why did it fall out of favour? (I left web development to write applications/C, then returned some years later to write APIs but everyone had stopped using it).

InclinedPlane 13y ago
Perl has stagnated, it's as simple as that. There are so many alternatives out there that have picked up where Perl left off or gone in new directions and covered some of the same ground that the competitive value of Perl has diminished over time. I consider Ruby, for example, a more evolved Perl in a lot of ways. Perl used to be the go to language for scripting and automation (practically what it was designed for) but now that niche is also filled with Python, Ruby, node, power shell, and improved automation tools like puppet, chef, or ansible. Perl also used to be the go to language for dynamic web applications but it fell behind as other languages gained ground and especially as sophisticated frameworks like rails put Perl development to more and more of a comparative disadvantage.
- chromatic 13y ago
  I consider Ruby, for example, a more evolved Perl in a lot of ways. Hopefully not in strength of module system, automated testing, extension mechanisms that aren't monkeypatching, quality of core development practices, metaprogramming (if you count Moose or p5-MOP), documentation, lexical scoping, or Unicode support.
daemonburrito 13y ago
This is just a personal opinion, but I also wrote Perl (back in the 90s), and I think that TIMTOWTDI was the reason that it fell out of favor. TIMTOWTDI makes it hard to share code, even between masters. I believe it's the source of the "Perl is unreadable" meme. Because everyone is capable of defining their own personal dialect of Perl, no solid, common subset emerged. Compare with the Zen of Python: "There should be one – and preferably only one – obvious way to do it." In Python, it's generally very easy for two similarly-skilled Python hackers to share code. It looks like a Wikipedia editor shares this view: http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_...
- slashdotaccount 13y ago
  > no solid, common subset emerged That's wrong. This common subset converged through consensus and finds expression in e.g. the Modern Perl movement, the module collection Task::Kensho and the updated motto "There is more than one way to do it, but sometimes consistency is not a bad thing either".
  - smacktoward 13y ago
    All of those things emerged long after Perl had ceded its position in the language marketplace. It's great that Perl has them now, but the process of working them out took a loooong time.
    - chromatic 13y ago
      Isn't that the case with every New Jersey language?
- riffraff 13y ago
  ruby flourished while perl was going down, even though it also shares TIMTOWTDI.
  - tl 13y ago
    Ruby flourished largely due to rails which ends up being pretty opinionated about how to do things.
  - bunderbunder 13y ago
    Yup. Which is why I'm personally a bit uneasy about Ruby's long-term future. It's attractive for the same reasons that Perl was attractive, but that means it also invites some of the same issues that Perl experienced. Wild speculation follows: There's always a need for a solid "just get shit done" language, but maybe any good language in this space is doomed to die by its own success. Crufty, hard to maintain code accumulates over time, because quickly banging out code you don't expect to still be maintaining in 10 years is the whole point. As that cruft accumulates, people start noticing it and inevitably blame the language. That leads to casting about for the next "just get shit done" language, and the cycle repeats.
slashdotaccount 13y ago
It didn't fall out of favour, Perl usage is growing every year. The "market" expanded as a whole, admitting newer languages. http://blog.timbunce.org/2008/03/08/perl-myths/ http://blog.timbunce.org/2008/03/08/perl-myths/
- kbenson 13y ago
  While I sympathize with that position, I think it glosses over some important implications. When the market expands rapidly, but you share does not, you are either missing new entrants, losing existing adherents, or some combination thereof. Most importantly, your relevance is shrinking even if your market share is not. That said, it is an important morale booster to know it's not actually shrinking. Note: You and your in this case is meant generally, as it most definitely includes me.
  - chromatic 13y ago
    When the market expands rapidly, but you share does not... My collection of Programming Books Which I Will Discard Before I Ever Move Them Again includes a book about CGI programming with the Korn shell. I am not making this up. As you well know, back in the day when CGI was magic and server-side includes were amazing, there weren't a lot of options for server side programming. You had C, if you were a Unixy systems programmer and didn't mind doing string processing in C. You had Tcl, if you wanted to go the AOLserver route. You had whatever shell script you wanted, if you wanted to pipe and stream together Unixy commands. After a time, you even had server-side JavaScript, if you spent a lot of money on Netscape server products. You also had Perl, which ran on just about every Unix under the sun and behaved the same way pretty much everywhere. Even if you couldn't rely on one Unix utility behaving the same on every Unix variant (unless you somehow managed to get the GNU tools installed), you could rely on Perl being just about everywhere. Better yet, it had a fair library of code being developed and published because people were sharing it. In the early days, you might have to use a Perl fork to connect to an Oracle or a Sybase installation, but you even had that option. (Yeah, you could do that in C too, but that would be borrowing pain far beyond string handling in C.) It's pretty easy to see why Perl ended up with a lot of that market. It fit that niche which hadn't previously existed, and there wasn't much competition. (Korn shell. Korn. Shell.) The market expanded rapidly. Then the competition expanded rapidly because the market expanded rapidly. It's innumerate to suggest that the relative position of market share will remain the same or even grow when the market grows so rapidly and so much competition appears.
smacktoward 13y ago
It was Perl 6. As soon as it became clear that the move from 5 to 6 was going to be discontinuous, if you wanted to be a Perl developer you had to decide if that meant being a Perl 5 developer or a Perl 6 developer. Being a Perl 6 developer was the clearly marked path to The Future, but Perl 6 was years away from being ready to use in production environments, and it never seemed to get any closer. Perl 5 was practical for real-world use, but choosing to be a Perl 5 developer meant worrying that you were investing time and energy learning skills that were already marked as obsolete and writing code that would end up having to be re-written. That kind of uncertainty is fatal to a language. Why put up with it when there's so many other languages out there with clear upgrade paths? Especially when the upgrade path for the one you're using now appears pretty similar to learning a new language anyway? So developers drifted away from Perl to other languages, and that, as they say, was that.
- baudehlo 13y ago
  I was once one of the most prolific authors on CPAN, and this, along with my answer above about lack of performance, drove me away. Perl(5) just needed classes and clean up a few bits of historic cruft (like the need to end modules in "1;", indirect object syntax, etc) and it could have been an awesome language. Perl6 decided to throw the baby out with the bathwater.
- slashdotaccount 13y ago
  Ah, that old chestnut again. The argument falls down when we see what really happened: Perl 6 had and continues to have a huge positive influence on Perl 5, the future belongs to both as there turned out to be no discontinuous move, and Perl 5 stays up-to-date.
  - Peaker 13y ago
    Even if it is only the way things are perceived, and not the actual truth - it can still explain the decay of the community.
    - draegtun 13y ago
baudehlo 13y ago
Along with the other excellent answers, one thing Perl never got was a faster runtime. This drove me into the arms of V8 (via Node.js). Ruby got jRuby and Rubinius, PHP got the excellent work Facebook did, Python got PyPy, and many cool languages started to appear on the JVM. Perl got stuck with /usr/bin/perl. Having said that, the internals of Perl continue to improve in the current interpreter, and there's some long standing amazing work such as the incredible performance of the DBI drivers (look at the techempower benchmarks to see how well Perl shines even versus Node.js when it comes to database access). I still use Perl for small scripts, but I'm just not building anything big in it these days. Perl6 was a huge lost opportunity, and a massive failure in vision and leadership.
tenfingers 13y ago
Programming languages are often too associated with popularity, and the "big products" which have been produced with it in the last few years. Being "old", especially in the startup world, is already a big negative. This has been applied to the numerous proprietary languages which were popular during the 90' for web development, and it will happen again to the current popular choices. Perl by itself has very little to do with it. I've seen "worse" languages become popular and fade away.

kanatohodets 13y ago

Interesting to think about the sorts of cultural markers that other languages have. Maybe this is just another way of saying 'code smell', but there must be similar elements for JS/Ruby/Python (for example) where it the code isn't strictly 'wrong' (or even debatably wrong), but is still clearly indicative of a particular cultural approach towards coding in that language. Like overriding Array.prototype.push in JS - it might be just fine, but I tend to pause and re-evaluate my attitude towards the code when I see that going on, because it's a very different approach to coding in JS than I personally use.

mattmanser 13y ago
I tend to see much clearer indicators in JavaScript code. Global variables? Lots of functions outside any closure? Old skool js coder ahead. You can also tell javascript only programmers a mile off. Anonymous functions everywhere? Functions have multiple concerns? Use 'var aFunction = function()'? Mono linguist and spaghetti code ahead.
- baudehlo 13y ago
  A lot more JS coders could benefit from adding "use strict" to their code too. It's frankly amazing it isn't used more.
  - Mithaldu 13y ago
    Honestly, in practive it falls short and doesn't do nearly enough. :(
    - baudehlo 13y ago
      True. It does far too little at compile time. I don't understand why. Maybe we need a "use compile strict" ;)
- losethos 13y ago
  My compiler is better than C/C++. If you do not have arguments, you do not need parenthesis on function calls. You are a nigger. I wrote a compiler. If you were not a nigger, I might have thought you found my "PAREN_WARN" compiler option. I have different precedence rules for my language, so to keep everybody on their toes, I give a warning if you have extra parens.

darbelo 13y ago

Worth reading even if you aren't a perl guy. Every language has this type of 'cultural markers' that set your expectations for a codebase by skimming a few files or just the project structure. On that first dive into someone else's code[1], this markers are invaluable, they are the first cue into the author's mindset and background. They are a signal for future maintainers or collaborators. It's like stepping off the plane and hearing people around you speak with your own regional accent. Even if you've never been here before, now you know some of your knowledge still applies. [1] Rule of thumb, if you haven't touched your own code for a long time, think of it as being written by someone else. You are not the same person you were when you wrote it.

Zancarius 13y ago
> Rule of thumb, if you haven't touched your own code for a long time, think of it as being written by someone else. You are not the same person you were when you wrote it. This is really insightful, most especially the part I italicized. I can think of a few particularly embarrassing moments when I've dug through old code of mine and immediately thought "What kind of idiot wrote this crap?" followed by a brief moment of horror when the realization sets in that the idiot was me. :) I think it would also make a fantastic addendum to this [1] discussion (and the article to which it is attached), especially since many new programmers often don't think much of code maintenance. Usually it's comprised of "I (or someone else) will eventually rewrite this." Then it enters production. [1] https://news.ycombinator.com/item?id=6789504 https://news.ycombinator.com/item?id=6789504
- hsmyers 13y ago
  Can't step in the same river twice is true in all domains, not just software. Admittedly with some languages it is worse than others, assembler and APL come to mind but same truth still applies.
- Groxx 13y ago
  I've come to (try to) document / code like I assume the next person reading it will be both insane and stupid. Usually that's me. Usually it was worth the extra effort :) And at the very least it's a measure of progress, as I'm no longer that insane and stupid.

leokun 13y ago

I just don't understand why anyone developing a language would think dynamic scope would be a good idea.

geocar 13y ago
Richard Stallman gave an excellent use and rationale for dynamic scope in the EMACS manual: http://www.gnu.org/software/emacs/emacs-paper.html#SEC17 http://www.gnu.org/software/emacs/emacs-paper.html#SEC17 One of my favourite things about perl and CL is the ability to have lexical (my/let) and dynamic (local/special) scope in the same program depending on what is clearer. In fact, it comes up often enough that programming in a language lacking dynamic scope (e.g. basic, JavaScript, or python) feels limiting sometimes, and I end up emulating it (settings+extend, observables, etc).
- jlgreco 13y ago
  That rationale may be a bit revisionist, here is Olin Shivers' take on RMS's justification for elisp's dynamic scoping: "Some context: Common Lisp did not exist (the effort was just getting underway). MIT Scheme did not exist. Scheme was a couple of AI Lab tech reports and a master's thesis. We're talking the tiniest seed crystal imaginable, here. There was immense experience in the lisp community on optimising compiled implementations of dynamically-scoped languages -- this, to such an extent, that it was a widely held opinion at the time that "lexical scope is interesting, theoretically, but it's inefficient to implement; dynamic scope is the fast choice." I'm not kidding. To name two examples, I heard this, on different occasions, from Richard Stallman (designer & implementor of emacs lisp) and Richard Fateman (prof. at Berkeley, and the principal force behind franz lisp, undoubtedly the most important lisp implementation built in the early Vax era -- important because it was delivered and it worked). I asked RMS when he was implementing emacs lisp why it was dynamically scoped and his exact reply was that lexical scope was too inefficient. So my point here is that even to people who were experts in the area of lisp implementation, in 1982 (and for years afterward, actually), Scheme was a radical, not-at-all-accepted notion. And outside the Lisp/AI community... well, languages with GC were definitely not acceptable. (Contrast with the perl & Java era in which we live. It is no exaggeration, thanks to perl, to say in 2001 that billions of dollars of services have been rolled out to the world on top of GC'd languages.)" http://www.paulgraham.com/thist.html http://www.paulgraham.com/thist.html (emphasis not my own) That whole page is a good read, particularly if you are a fan of Shivers' writing style.

bane 13y ago

I find that when I use 'struct' in my Perl, I have a psychological mind shift in how I write the code. Instead of hacking together some code, I start to take it more seriously, and start to care about everything from what I choose as my variable names to the overall sructure of the code. I start to care about maintainability. To be honest, I end up eliminating lots of clover Perl idioms and make the code much more 'C' and Java like, explicitly declaring most of my variables at the top of functions and making them verbose and consistent. I start to document everything and write lots of comments explaining what I'm doing. It really doesn't add much overhead to the overall development to be honest. I think as if I have to give the code to somebody else, even if that other person is me in the far future. It's served me well, I've returned to old pieces of code I wrote years before (even multiple 10s of KLOCS) and after a couple read through was able to get to work without much fuss. Fitting in with Larry's idea of programming languages as real languages, it's as if I've code-switched from a colloquial language to the kind of formal language I might use when giving a presentation.

Mithaldu 13y ago
> explicitly declaring most of my variables at the top of functions While i largely agree with the rest of your code, that one bit i can't generally agree with. If you take care to keep all your functions below 15 or so lines, i.e. such that they fit on one screen, then that's fine. As soon as you write bigger functions you end up impacting your code quality in two ways: - readability and refactorability go down, because coders after you have to read more code to see the context of a variable - the chance of bugs goes up because you're more tempted to reuse a predeclared variable in a loop, instead of redeclaring it at every start of a loop; or more insidiously, reuse the same variable as the counter in multiple loops So please: Declare your variables as late as humanly possible, optimally only directly before they're used.
- bane 13y ago
  I don't disagree with your points at all. Short life variables I do tend to declare later in the code. But most of the major state variables (especially the ones that get returned, or important data structures I want to keep track of in the code flow) I stick at the top with comments and explanations of what the variable is and why it exists.

jfb 13y ago

As the child of anthropologists, I think there's a lot of room for cultural analysis of technologies. Languages, for instance, have cultures as well as affordances, and a careful comparative analysis would be really interesting.