tag:blogger.com,1999:blog-27488238.post510989631407251996..comments2024-03-22T11:34:45.165+01:00Comments on taw's blog: Yannis's Law: Programmer Productivity Doubles Every 6 Yearstawhttp://www.blogger.com/profile/16972845140253292628noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-27488238.post-75131024505938870842013-12-08T13:51:53.931+01:002013-12-08T13:51:53.931+01:00It's more beautiful to do this:
words.size....It's more beautiful to do this:<br /><br /> words.size.times {<br /> res_lines << words.join(' ')<br /> words.push(words.shift)<br /> }Eldcnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-39792489865360214632013-10-05T20:01:10.728+02:002013-10-05T20:01:10.728+02:00talking about programmers' productivity...
Th...talking about programmers' productivity...<br /><br />There's a new excellent code-editor extension called Flow.<br /><br />Really improves productivity by automating the process of browsing through Q&A sites (like StackOverflow)<br /><br />http://www.flowextension.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-45162949696591876212012-09-22T14:23:33.932+02:002012-09-22T14:23:33.932+02:00Everybody seems to point at 1978's appearance ...Everybody seems to point at 1978's appearance of Awk.<br /><br />But, as an anonymous poster mentioned earlier, by 1972 Lisp had 14 years of existence, multiple implementations, with Lisp-specific hardware soon to follow.<br /><br />Lisp was so prominent in the 60's and 70's, that the first book on Lisp history was published in 1979, written by Herbert Stoyan.<br /><br />According to these materials, by early 1970's, Lisp was used to build systems of AI, computer algebra, circuit analysis and simulation, symbolic integration, proof automation, data visualisation (Quam67) and expert systems.<br /><br />For an index to Lisp history materials, you might want to see:<br />http://archive.computerhistory.org/resources/text/FindingAids/102703236-Stoyan.pdfAnonymoushttps://www.blogger.com/profile/13558720912835671862noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-34688055848406278152010-05-03T09:34:30.778+02:002010-05-03T09:34:30.778+02:00npe, you obviously neither understood the original...npe, you obviously neither understood the original description nor ran or read the ruby code. You missed the 'all circular shifts' part. When there is a line 'a b c', the output must also contain the lines 'b c a' and 'c a b'.Andreas Kreyhttps://www.blogger.com/profile/18011171943440483489noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-33861161230746233072010-05-02T19:59:22.221+02:002010-05-02T19:59:22.221+02:00npe: Thank you for proving my point, as your "...<i><br />npe: Thank you for proving my point, as your "1977's programmer" version doesn't do anything remotely like what it needs, so this "1977's programmer" would spend another week or so debugging.<br /></i><br /><br />Not sure if I follow what you mean. Could you elaborate?Noahhttps://www.blogger.com/profile/05613016914745268008noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-24195292879367722132010-05-02T18:50:28.350+02:002010-05-02T18:50:28.350+02:00npe: Thank you for proving my point, as your "...npe: Thank you for proving my point, as your "1977's programmer" version doesn't do anything remotely like what it needs, so this "1977's programmer" would spend another week or so debugging.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-38353167578547773082010-05-02T18:08:27.836+02:002010-05-02T18:08:27.836+02:00I'm a little late to the party but this is wha...I'm a little late to the party but this is what a good 1977 programmer would have wrote.<br /><br />awk '{ word=$1; $1=""; gsub("^[ \t]*", ""); print $0,word}' <lines | uniq | sort<br /><br />There have been major advances in programming but old school unix is still the be all and end all of text processing.Noahhttps://www.blogger.com/profile/05613016914745268008noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-67109985603869933352010-04-29T14:18:55.137+02:002010-04-29T14:18:55.137+02:00People are making Pacman-style games in Flash in a...People are making Pacman-style games in Flash in a few hours these days, but thanks to the increased productivity completely new kinds of games are possible.IT Outsourcing Companyhttp://s4support.com/services_prices.htmnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-48859450402015388922010-01-22T11:17:33.292+01:002010-01-22T11:17:33.292+01:00wonderful code for the kwic index!!!!.
richard
po...wonderful code for the kwic index!!!!.<br /><br />richard<br />portal0001@lycos.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-2560615410480258422009-01-15T22:04:00.000+01:002009-01-15T22:04:00.000+01:00We are still deeply stuck into c++ and the sad tru...<I>We are still deeply stuck into c++ and the sad truth is that most of game programmers have a solid aversion towards anything that is higher level.</I><BR/><BR/>Thank you, Anonymous. You are the only one here who is talking about serious real-world scenarios instead of toy problems. This is work, not the fantasies of some dreamer. Your job deals with mission-critical applications such as weapons systems, trajectories, full-detail simulators. For those, it's c++ or nothing!Ralph Dratmanhttps://www.blogger.com/profile/00426433134164984467noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-84662952195253698802008-02-17T10:18:00.000+01:002008-02-17T10:18:00.000+01:00taw said : "I don't know about too many games stil...taw said : "I don't know about too many games still coded in C++ without something on top of it. Most have C++ engines, but the engines are just libraries shared between multiple games. The games by themselves tend to be coded in some high-level language, either engine-specific or something generic like Lua, with only small parts still coded in C++."<BR/><BR/>Oh, I just wish it were true :)<BR/>I am a programmer in the game industry for almost 10 years now and I can tell you from both personal experience in the companies I worked in (and still do) and from following Game Developers Conference "publications" that we are really very very far from it.<BR/>Lua is a good example of a "high" level language that is more and more used, but only to offer assistance to game and level designers in scripting the game characters behaviors and general gameplay. It's certainly not used at all by the engine programmers. We are still deeply stuck into c++ and the sad truth is that most of game programmers have a solid aversion towards anything that is higher level.<BR/><BR/>This industry is so young and immature that the teams are under too much pressure to even think of looking outside the small world of game development for possible evolutions. It's beginning to change, but in very restricted areas (read, a handful of small companies, no more) and I really don't expect us to experiment with higher level languages in the game engines before at least 5 years (and that's optimistic).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-16607194691441600222008-02-05T17:16:00.000+01:002008-02-05T17:16:00.000+01:00And another question is how much of the allotted w...And another question is how much of the allotted week goes into documentation? Getting a slot on the test machine?<BR/><BR/>Working around the fact that you only have 128k memory, and can't assume to be able to sort your data in main memory?<BR/><BR/>Yesterday I hacked a little ruby script to find some jitter in a log file. The file was 1/2 Gig, and so was the ruby process after reading it into hashtables (after five minutes).<BR/><BR/>You'd have an interesting time even implementing ruby on the machines of those days! Overlays, anyone?Andreas Kreyhttps://www.blogger.com/profile/18011171943440483489noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-70519413056770839262008-01-15T16:03:00.000+01:002008-01-15T16:03:00.000+01:00How much speed is gaind just due to faster compute...How much speed is gaind just due to faster computers? You don't have to optimize your routines as much as you had to 20 years ago. More optimized code is harder to maintain as it often hides the underliing algorithm, etc.<BR/>Than there are way faster compiletimes, etc.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-26769709508124239642007-04-19T03:39:00.000+02:002007-04-19T03:39:00.000+02:00Jonathan: Back in pac-man era game programmers cod...Jonathan: Back in pac-man era game programmers coded in assembly, not in C. In fact in early 1990s people were making a big deal of out <A HREF="http://en.wikipedia.org/wiki/Doom" REL="nofollow">Doom</A> being coded mostly in C, with only small pieces in assembly.<BR/><BR/>I don't know about too many games still coded in C++ without something on top of it. Most have C++ engines, but the engines are just libraries shared between multiple games. The games by themselves tend to be coded in some high-level language, either engine-specific or something generic like Lua, with only small parts still coded in C++.<BR/><BR/>That's a long road since early 90s, from pure assembly to mostly Lua (or something at that level) with a bit of C++.tawhttps://www.blogger.com/profile/16972845140253292628noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-33703906520389470092007-04-19T03:13:00.000+02:002007-04-19T03:13:00.000+02:00We have mostly concentrated on languages here in t...We have mostly concentrated on languages here in terms of productivity - however taw originally mentioned something far more valuable, which was <I>methodology</I>. In particular he mentioned <B>test first</B> strategy.<BR/>This I know from experience improves productivity - even if you shorten it to simply <B>unit testing</B>. I know my code produced via solid unit testing took longer than the other guys <I>at first</I>. But months after my code was released, the others were still trying to get their code release ready after multiple iterations to QA, I was smoking my cigar (OK well I don't smoke literally) with only having to touch one up issue discovered after much (_much_) testing ... More productive? Absolutely.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-21557936696824695542007-04-19T03:05:00.000+02:002007-04-19T03:05:00.000+02:00taw started saying the gaming example was a good o...taw started saying the gaming example was a good one. That seems rather amusing to me - since the gaming companies are usually advertising for <B>C++</B> developers - surely a rather unproductive language to be using in the mid-naughtie's !<BR/>Yet you agreed we were more productive now, than pac-man coded in ... well I don't know, but surely C or basic?<BR/>So are we more productive? probably - because as pointed out by others, we have more <I>libraries</I> to not repeat ourselves over and over ...<BR/>As pointed out already, Ruby is more productive - for a small subset of problems, period!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-20923966175259649672007-03-23T05:06:00.000+01:002007-03-23T05:06:00.000+01:00First, the Ruby program doesn't actually produce a...First, the Ruby program doesn't actually produce a KWIC index, it hasn't indexed anything (it needs line numbers or page numbers, or something to reference the source text), so an extra 10 minutes to test, discover the error, and correct it seems reasonable.<BR/><BR/>Second, I believe a competent awk programmer on Unix, would deliver the correct results within 15 minutes (I'm very rusty, so I'd take longer :-(<BR/>I think a pipeline like<BR/>awk '... permute lines ...' < file | sort | uniq | awk ' ... rotate lines and format ...'<BR/>would do it (missing the option flags, sorry :-)<BR/><BR/>Awk has been available since 1977/78 (http://www.softpanorama.org/History/Unix/index.shtml).<BR/><BR/>So, I would suggest that <B>ALL</B> of the productivity was gained by 1978, and by Yanni's measure, almost no productivity gains have happened in the subsequent 30 years (sorry Yanni the function looks much more complex and less satisfying !-)<BR/><BR/>Our apparent productivity has come via hardware which is so fast and capable that we don't need to write using 'high performance' but unproductive tools as often; many of the productive tools and technologies have existed for years, waiting for the hardware to catch up, and new generations to embrace them.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-23185637841541846662007-03-10T09:25:00.000+01:002007-03-10T09:25:00.000+01:00Fab writes: "Your comparison with Parnas's assignm...Fab writes: "Your comparison with Parnas's assignment is unfair"<BR/><BR/>Fab has a good point. I could define a language with a built-in function to do the KWIC test with a single keyword. Does that make me 25 times better than Ruby? Knocking out KWIC implementations is meaningless.<BR/><BR/>'Ahah' you say. But I can still call 'kwic' in one word from my language, so I'm still faster. 'But' I reply 'does your language have a pacman function, or gearsofwar or accounts_receivable function? No.<BR/><BR/>Nevertheless, interesting how much good programmers can get so much faster. Not everyone does though!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-61529775911445077622007-02-21T12:08:00.000+01:002007-02-21T12:08:00.000+01:00kwic's not a good example here. The ability to spl...kwic's not a good example here. The ability to split lines and sort lists is built into modern languages like ruby. Productivity increases are based on library code instead of any inherent improvements in the language. <BR/><BR/>Not saying that libraries aren't good and don't improve productivity, but the example you quoted seemed almost purpose built to show off ruby. <BR/><BR/>It's like sayiny my new language "e" is great because it has a built in "kwic" function. <BR/><BR/>newlist = new (kwik(system.oldlist))<BR/><BR/>I wrote that code in three seconds, but it's no way to identify how good the imagined "e" language may be.Special Clownhttps://www.blogger.com/profile/05125412182236565538noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-68855977235534008172007-02-20T19:48:00.000+01:002007-02-20T19:48:00.000+01:00You are correct that in software people are consta...You are correct that in software people are constantly working on new things, and possibly using new tools (this depends on familiarity, circumstance, etc). <BR/><BR/>People I know however mostly interpret that to be what Brooks means - 1/10th of the effort would always be the essense - you cannot reduce it to zero, because it requires thinking. <BR/><BR/>So that's why you are getting many comments correcting your assertion on Brooks, even though your conclusion is correct. <BR/><BR/>Increase in Productivity != Silver Bullet.ychttps://www.blogger.com/profile/11915946249340014269noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-65865186616583306022007-02-20T08:53:00.000+01:002007-02-20T08:53:00.000+01:00In his follow-up essay '"No Silver Bullet" Refired...In his follow-up essay '"No Silver Bullet" Refired', he says "The part of software building I called essence is the mental crafting of the conceptual construct; the part I called accident is its implementation process." I would interpret this to mean that the tools can get better and better, but we're always going to be building something new, and building new things is inherently difficult. <BR/><BR/>While it may take 4 minutes to do KWIC now in Ruby vs. a week in Assembly on a mainframe (since Brooks was on the original OS/360 team), it's a toy example. The problem has in inherent low essential complexity, so most of the complexity is accidental - you just have to write the code. If you were building an OS or an on-board flight control system (as Parnas did for the A7E), the essential complexity is a much greater proportion of the overall complexity. Brooks says in "Refired" that even if the accidental complexity is 9/10ths of the total complexity, shrinking it to zero would be the only way to give an order of magnitude.<BR/><BR/>One of the other things that may also affect the outcome here is that powerful tools like Ruby have abstracted away the cruft of programming that previously existed and programmers are allowed more time to think about the essence, so they hone their essence skills much more than their accidental skills.phil varnerhttps://www.blogger.com/profile/11167295487172421470noreply@blogger.comtag:blogger.com,1999:blog-27488238.post-25396225558152212982007-02-20T04:27:00.000+01:002007-02-20T04:27:00.000+01:00I think Brooks is talking more about complete syst...I think Brooks is talking more about complete systems development rather than discrete bits of coding. You did effectively show that individual programmers can do specific things much more quickly than before but something major like a back-end system for a bank takes as long as it always has if not longer.<BR/><BR/>Admittedly, most large systems do more than they ever did in the past but people on the business side tend to think "how come I can't just click my fingers and have a fully operational system in place?" Because there's no silver bullet.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-8959137235364862872007-02-19T23:54:00.000+01:002007-02-19T23:54:00.000+01:00[[To me that sounds like "We were able to increase...[[To me that sounds like "We were able to increase productivity in the past only because we were reducing accidental complexity. Now the complexity left is mostly essential complexity, and there's just no way to get around this complexity, ever". That's also how most people seem to be interpretting the essay.]]<BR/>Not true. Brooks did list in his essay the things that promise to effectively tackle the essential complexity such as reusability, incremental development process, education etc. What I learnt from the essay was that the inherent characteristics (invisibility, changeability etc.) of software make it hard to tackle the essential complexity of software construction, but it is not impossible. <BR/><BR/>[[You can claim that Brooks was right, because the >10x productivity increase was due to combination of techniques, not a single technique, and that it took longer than a decade, but even if you do so, the very concept of "essential" vs "accidental" complexity needs to be thrown away.]]<BR/>I kinda agree with this. I think it's hard to separate between the essential and accidental difficulties. Brooks considered the high-level languages as the attack to the accidental difficulty while leaving the essential (design process) untouched, but that is not true - the amount of design process needed for a Ruby project is much less than that for an Assembly project, given the same problem to be solved.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-62358397217121116862007-02-19T21:10:00.000+01:002007-02-19T21:10:00.000+01:00A Lisp implementation of the KWIK similar to the R...A Lisp implementation of the KWIK similar to the Ruby example can be done in a few minutes. Given that Lisp was a tool that existed by 1972, one could argue that indeed, there hasn't been much improvement in productivity.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27488238.post-88465945855407718612007-02-19T21:00:00.000+01:002007-02-19T21:00:00.000+01:00Your comparison with Parnas's assignment is unfair...Your comparison with Parnas's assignment is unfair - The exercise required the development of all subsystems, including persistence, I/O, etc... from scratch - The point of the article was the decomposition of a big systems into modules, not how to write it as fast as possible. Libraries existed already in the 1970s and this could be probably done in less than 1h, without constraints. IMHO the "real" productivity boost since 1970 is far less than your estimation - although I can't really put it in numbers.fabienhttps://www.blogger.com/profile/17424755243873048086noreply@blogger.com