7 ms·
Python as an Alternative to Lisp or Java, Peter Norvig revisited
- jamesaguilar 16y agoI wonder how short a good Java programmer's solution would be compared to the J Random Java Programmers used in the study so long ago.
- 6ren 16y agoHN comment by Norvig on Lisp vs. Python http://news.ycombinator.com/item?id=1803815 http://news.ycombinator.com/item?id=1803815
- SpikeGronim 16y agoTo me, it's not interesting at all to ask who can write a 100-1,000 line program faster in which language. The real interesting question is how efficient developers are once you're talking about a 100,000 - 1,000,000 line program that has been in development for years. Solving small problems is relatively easy.
- kingkilr 16y agoI'll turn that on it's head. To me the interesting question is: do you need 100,000 or 1,000,000 lines to express the same ideas?
- kbd 16y agoAnd if you assume a relatively stable bug/loc ratio...
- kenjackson 16y agoSo are you saying we don't need emacs?
- ntoshev 16y agoHe is saying an Emacs in Java would be 10x as big.
- kenjackson 16y agoSo he's saying that a Java version of Emacs would be 10 million lines of code long? That's ridiculously unlikely, unless given to monkeys to code -- and even then incompetent monkeys. This is just wishful thinking.
- andrewcooke 16y agoEclipse was 18 million lines in 2008 - http://eclipse.dzone.com/articles/eclipse-ganymede-18-million-li http://eclipse.dzone.com/articles/eclipse-ganymede-18-millio... Obviously it's not a direct comparison, but...
- gphil 16y agoWow, that is the biggest codebase I have ever heard of. Does anyone know of anything bigger than that?
- 16y ago
- jackfoxy 16y agoThis is the kind of article that should more frequently come to the attention of enterprise management. There really is an inverse relationship between the expressiveness of a language and the number of bugs created. (That is, I am taking at face value the studies which claim a more or less linear relationship between lines of code and bugs, regardless of language.)
- aharrison 16y agoI have heard this before many times, and I tried to find a study that would defend that assertion one weekend and failed miserably. If you have a citation for one of those studies I would be in your debt.
- jackfoxy 16y agoFound this http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html http://amartester.blogspot.com/2007/04/bugs-per-lines-of-cod.... Thanks for calling me on that, I was just repeating the popular assertion.
- deleted 16y ago[deleted]
- technomancy 16y agohttp://p.hagelb.org/csb.gif http://p.hagelb.org/csb.gif
- xorglorb 16y agoHacker News is not 4chan, and as such, do not reply "Cool Story Bro", unless you are replying to your brother that you thought the story he gave you was popular.
- barnaby 16y agoI upvoted you and downvoted him because I really don't want HN to degrade into Reddit/Digg/4Chan/etc. I come here specifically because it's _not_ one of those, and has a good signal-to-noise ratio (e.g. relevant conversations not overrun by silly memes)
- Apocryphon 16y agoWhat about Metafilter?
- Stormbringer 16y agoI wonder if another, equally valid, way of looking at the lines of code vs time is that if two programmers using different languages both complete the task in roughly the same amount of time, but one uses only half the total lines of code... that implies _not_ that that programmer is better, but that each of their lines of code took roughly twice as long to produce. One of the things I used to do when working in large teams was wander around and look to see if anyone was having trouble debugging. Sometimes you'd find someone who'd been stuck on a bug for several days. So what I'd do was I'd sit down with them, and start putting in all the 'fluff' like indenting their code, splitting lines with multiple variable declarations each onto their own line etc. Essentially putting in all the 'long cuts' that they'd taken 'short cuts' around in order to 'speed up' the programming. Often either they or I would see the problem immediately. These days of course there are tools that do the auto-formatting, but I still try to optimise for readability, simplicity and elegance in my code. Back to the lines of code as a metric issue (tm) in that scenario where it takes 2x as long to write a line in language X, and that line does twice as much, it is probably at least twice as complex as the 'more verbose' language... and I think this implies that it will be harder to debug and maintain later on. So arbitrarily complex languages are optimal for some internet 'toss off' (one off, toss away) competition, but not necessarily optimal for long term efforts. Some of these languages that allow you to redefine the language itself on the fly allow you to do 'cool stuff' (tm) but tend to attract people who think they are much cleverer than they actually are. I think it is a regional variation, but all the Ruby fans in my city scare me. The thought of what would happen if I'd spent days or weeks on a bug only to find out it was caused by someone else 'tweaking' one of the core classes and not bothering to tell anyone else... twitch
- ay 16y ago"scenario where it takes 2x as long to write a line in language X, and that line does twice as much, it is probably at least twice as complex as the 'more verbose' language... " I think this is debatable. After all - a function call compresses multiple lines into one as well.. And you want programmers to factor the repeated code into function calls. The "dynamic redefinition of the language" is the same thing except at a different level. The problem is not with the lines of code per se - it is whether the semantic compression is worth the learning curve, and the "surprise" factor. Think C++ templates, for example, with a "+" operator that would do something "non-intuitive". The "non-intuitiveness" may vary - and it is a fine art to not cross the line. FWIW, I've done the exercice in Lua, ~ 1 hour and 107 lines (and for some reason a different order of outputs, which I did not want to debug since I went for a nice dinner with a couple of beers earlier today) - https://gist.github.com/752460 https://gist.github.com/752460
- dilap 16y agoAnyone try the puzzle? The following does not occur in the sample output, but I don't understand why: /78698/37395746288: Koch 8 Sud Hab Tirol What did I miss in the rules?
- ay 16y agoViolates this requirement: "If and only if at a particular point no word at all from the dictionary can be inserted, a single digit from the phone number can be copied to the encoding instead." The number you mention allows to get into the branch with the 'Koch o"d' - so no digit can be selected.
- dilap 16y agoAha! Yep, that was the problem. Thanks! (I was reading the requirement as "If at a particular point no sequence of words from the dictionary can be inserted to complete the number, a single digit can be inserted" -- which still makes a lot more sense to me than the actual requirement!) Sadly, no programming language could have helped me with this bug. :) https://gist.github.com/752506 https://gist.github.com/752506
- DrJosiah 16y agoDon't feel bad, I hit the same bug myself. :)
- bkz 16y agoThis version clocked in at 1:35, gave up on the "professional code" requirement though :) Need to sleep. https://gist.github.com/752455 https://gist.github.com/752455
- smackay 16y agoIt is surprising that in 2010 we are still talking about efficiency in terms of lines of code whether the absolute number to express a problem or in the speed that these lines can be created. I realise that this is a proxy for the ability of a language to succinctly express a problem however it ignores all the major factors that determine how effective a piece of code is over its lifetime. The ability of language X to solve a problem depends on: 1. The expressiveness of the syntax to capture algorithmic complexity. 2. The availability of tools to support the creation of the code. 3. The ability of the typical programmer, conversant in the language, to write the code. 4. The costs involved in maintaining the code over its lifetime. Rendering all these dimensions into a single metric seems simplistic at best, undermining the argument as to which set of tools and technologies are deserving of more attention and ultimately plays into the hands of the people who wish to render programmers and programming into pure commodities.
- davidhollander 16y agoFor the most EXTREME algorithmic compression of information to number of lines in Python (with few to 0 intermediate values stored), I've found it hard to beat using nested function definitions with abstracted shared logic called by running the vars() builtin as the parameter list. Basically ship the current scope elsewhere to finish processing to ensure no logic is repeated. I tend to not use separate URL mappers in controllers but have nested functions that define both logic and layout simultaneously. (Basically a tree structure of function definitions where the ending subpage elements are leaf nodes, and nodes render wrapper base templates on post traversal unless it was an ajax request). I can post some code if this doesn't make sense. Obviously not defining new variables nor using classes is extremely unpythonic and could pose difficulties for group work... minimum number of lines while fun isn't everything!
- apetresc 16y agoI saw Martin Odersky use this exact problem in a talk he was giving about Scala. It came out to about 10 lines.
- philwelch 16y agoNorvig: It took me about 2 hours (compared to a range of 2 to 8.5 hours for the other Lisp programmers in the study, 3 to 25 for C/C++ and 4 to 63 for Java) and I ended up with 45 non-comment non-blank lines (compared with a range of 51 to 182 for Lisp, and 107 to 614 for the other languages). Seems like the programmer, not the language, is the biggest determinant. If you have the Java programmer who wrote it in 4 hours, and the Lisp programmer who wrote it in 8.5 hours, you're better off writing it in Java! If you want to write concise programs quickly, using the same language Peter Norvig uses might help, but being as good as Peter Norvig helps more.
- wh-uws 16y agoYeah I really believe this is mostly about the programmer. It takes a different type of programmer to even want to venture to learn lisp in the first place.