Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 187

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 188

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 189

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 194

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 195

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 196

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 197

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 241

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 264

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 269

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 275

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 285

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 286

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 296

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 297

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 298

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 308

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 309

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 310

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 311

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 321

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 322

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 323

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 324

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 325

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 497

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 527

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 540

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 587

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 626

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 670

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 673

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 682

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 688

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 693

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 699

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 633

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 272

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 110

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 130

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 295
Didier Verna's Scientific Blog - Language wars - Comments Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff. 2024-01-31T17:45:28+00:00 Didier Verna urn:md5:a22c53786aff986a2da4c770c233a8f9 Dotclear Language wars - Didier Verna urn:md5:cb42670c68c577f8c67ee991bc235c81 2012-07-20T17:42:18+02:00 2012-07-31T09:06:34+02:00 Didier Verna <p>Alex: that was exactly my point. Languages, after all, are not just tools.</p> Language wars - McCarthy urn:md5:95fb0b82eee25ff22a8ce0c9f7b30a0a 2012-07-18T19:31:46+02:00 2012-07-20T16:40:00+02:00 McCarthy <p>delroth:</p> <p>"Is there any reason CL implementations are lagging behind implementations of other dynamic languages?"</p> <p>Very few dynamic languages are ahead of modern Lisp compilers. In raw performance, perhaps the only runtime that is consistently ahead of it today is the Java VM.</p> <p>"Is that because of some attributes of the language that don't allow the "common" VM optimizations (that "the guy in the audience" talked about: partial specialization, hidden classes, hotspot profiling, etc.) to be applied,"</p> <p>Do you know what these even mean? For example, why would you need "hidden classes" unless you were implementing a language like Javascript which didn't have proper classes to begin with? CL already has real classes. In what context could "hidden classes" be helpful?</p> <p>"or is it because people lack the time and/or motivation to implement a performant CL VM?"</p> <p>I'm gonna have to call "citation needed" on this one. But as long as we're trolling, I'll ask the opposite question. I wonder why in 2012, only one dynamic runtime is consistently faster than a free CL compiler, and most of the popular ones are much slower, in addition to being for less powerful languages -- is it because the languages were so poorly designed?</p> Language wars - Alex urn:md5:348aba07e217e51e869e1e446e628be1 2012-07-18T19:18:27+02:00 2012-07-20T16:38:34+02:00 Alex <p>"If you care about your specific instrument (not every musician does)" ... "I have met musicians that could play with any instrument, with any sound, and still be happy."</p> <p>Curious. I've never met a musician who did not care about their instrument. That doesn't mean they're unable to also have fun playing a plastic toy, if it's what's at hand.</p> <p>"Nobody, on the other hand, can criticize your hammer by looking at your house"</p> <p>This is a good point, in the case of hammers and houses, but I think this is more evidence that a programming language is not simply a "tool", in any sense listed here. The programming language usually does shine through in the final product. Does your URL have "index.php" in it? Does your error page have a yellow background? Does your native app use a different font, or does drag-n-drop not work right, or do the standard controls not animate in the standard way? (These are all actual things I've seen this week that announce the programming language.)</p> <p>Granted, if you took the time to polish every corner, then the language shouldn't be visible in the final product. But almost nobody does, or can. In software, there's just too many corners. For modern software with a reasonable feature set, there will always exist some user input that causes default behavior of your language/framework/libraries to show through. So usually, people can tell pretty easily what you used to build it.</p> <p>It'd be like having a house with little round indentations in a few places with "CRAFTSMAN" logos in them (if Craftsman was silly enough to put their name on the striking head of the hammer, like PHP does with their name in URLs). Your house will still be just as strong, but everybody who's spent at least 5 minutes in your house knows what kind of hammer was used.</p> <p>As one extreme case, look at Java apps, and look at how many people on the internet have asked for (back when Java was popular for writing desktop software) "a program to do XYZ, but native and not Java".</p> Language wars - Didier Verna urn:md5:a64b6b927c6d9f2706fb70f26b394b21 2012-07-15T11:50:56+02:00 2012-07-15T10:51:08+02:00 Didier Verna <p>Delroth: the trollness not only lies in what you say but how you say it. I don't think I have misquoted him, but in the heat of the moment, you never know :-). Of course the "other" points (the ones following the initial remark) are all valid, notably regarding hotspots etc. and I didn't argue about those.</p> <p>But he also knows better, and in particular, that sometimes, you cannot just fix the problem at its origin and need to work around it (otherwise, 80% of the autotools for instance, would simply not exist). Consider this: in Climb we wanted to figure out where exactly the code was statically typed vs. where it truely depended on some level of genericity, and how much performance we could get from optimizing for the static types, in the current implementation. I have one 1st year student to do that. Now what do you think was the reasonable plan: go and ask him to fix one (or seven) CL implementations by doing run-time hotspot detection (hint: that would require at least a Ph.D.), or work around the real problem and do it by hand ? ;-) No, there are times where you just need to be practical and reasonable.</p> <p>Of course, I would like to have all those neafty features in CL. However, and that also answers your final question: it really is a question of money and manpower, so this is not going to happen just today...</p> Language wars - Didier Verna urn:md5:209e8ca9299e0a6c351ff87e2850d8b0 2012-07-15T11:32:45+02:00 2012-07-15T10:32:58+02:00 Didier Verna <p>David: interesting, thanks for the links!</p> Language wars - Didier Verna urn:md5:dadc3fa8c26c6acf7204374ddaf89533 2012-07-15T11:30:09+02:00 2012-07-15T10:30:20+02:00 Didier Verna <p>Vsevolod, Sander: I totally agree about the importance of the "language" part in programming languages, and the relation to your way of thinking.</p> Language wars - Didier Verna urn:md5:961690ca90567c4efdf1e00edf361edc 2012-07-15T11:24:36+02:00 2012-07-15T10:25:03+02:00 Didier Verna <p>Paul: yes, you're correct. There can be wars about tools as well, as soon as you start to care (i.e. you put some personal involvement in them). Not to mention the fact that tools, because they are created as well, can very well be artwork themselves. You are also very correct about the fitness (or lack thereof) of a tool for a particular task. That's exactly why I have come to love Lisp. Because no language is perfect, I prefer to have many options. Lisp is not a tool, but a large toolbox in which you can pick the tools you need or prefer when you need them. It's even more than that: Lisp is also a factory for creating the tools you need if they don't come built-in. For me, it's much better to have this freedom, rather than being forced to, say, use objects all the time, or be statically typed all the time, or purely functional all the time etc.</p> Language wars - Geoff Wozniak urn:md5:c2d9e96594479bc0ea0b14cf259cab48 2012-07-14T15:40:33+02:00 2012-07-14T14:40:33+02:00 Geoff Wozniak <p>The analogy about the connection of an artist to their work and the coder to their language is demonstrated by the fact that in a lot of cases, when talking about code from one developer to another, a possessive adjective (or pronoun) is used. For example, "Your code doesn't work" or "His code is wrong". I do my best to decouple the code from the person ("The code is doing the wrong thing") but even when I do, it feels like I'm making a personal attack.</p> <p>As to language wars, I've never found them productive, yet we as a community continuously supply weapons for it. Projects often draw attention to their implementation language. By saying "Foo was written in C" you leave the reader to fill in the unwritten part: "so it must be fast and lean!".</p> Language wars - David Lamkins urn:md5:909b52a19d38ba91093f8c6de4e57909 2012-07-14T02:30:56+02:00 2012-07-15T10:31:41+02:00 David Lamkins <p>All of which is why we have "egoless programming", which sadly seems to have fallen out of fashion over the past decades:</p> <p><a href="http://articles.techrepublic.com.com/5100-10878_11-1045782.html" title="http://articles.techrepublic.com.com/5100-10878_11-1045782.html" rel="nofollow">http://articles.techrepublic.com.co...</a></p> <p>Also, I've found this useful across various creative disciplines:</p> <p><a href="http://www.amazon.com/dp/0961454733/" title="http://www.amazon.com/dp/0961454733/" rel="nofollow">http://www.amazon.com/dp/0961454733...</a></p> Language wars - delroth urn:md5:97521df66b0e8623cdc4f7c6c282fd64 2012-07-13T03:53:48+02:00 2012-07-15T10:34:30+02:00 delroth <p>I definitely agree with your point, but I think you misunderstood (and misquoted IMHO) the guy you categorize as a "troll" from the audience.</p> <p>What he was arguing is that the work that has been done by adding static typing manually in the Lisp code could have been implemented in a more generic way by improving the implementation instead of optimizing a specific library. He gave several examples of languages with very good implementations that can achieve good performance without static typing (Javascript for example), and I think he has a good point here: the work that has been done to optimize Climb will most likely not help any other Lisp code to run faster.</p> <p>Is there any reason CL implementations are lagging behind implementations of other dynamic languages? Is that because of some attributes of the language that don't allow the "common" VM optimizations (that "the guy in the audience" talked about: partial specialization, hidden classes, hotspot profiling, etc.) to be applied, or is it because people lack the time and/or motivation to implement a performant CL VM?</p> Language wars - Sander urn:md5:4f1f3117bfee3a5e01322ac9426580dd 2012-07-13T00:52:14+02:00 2012-07-15T10:28:38+02:00 Sander <p>A programming language is a language, one that you think in.<br /> Nobody likes to hear that the way they think is dumb, or that there is a more efficient way of thinking.</p> <p>That's also a reason why people can get a bit emotional when it comes to programming, it's way more personal.</p> Language wars - Vsevolod urn:md5:4f5cd1bf6d62d3f6877580d3287dee82 2012-07-13T00:06:11+02:00 2012-07-15T10:27:19+02:00 Vsevolod <p>I think, languages are more, than just tools. They shape how you think. That is important and can easily get personal, because you start to defend *your* point of view and perspective.</p> Language wars - Didier urn:md5:d822aabb7374480a9c63201a40ffaf66 2012-07-12T21:04:11+02:00 2012-07-12T20:04:11+02:00 Didier <p>Well, that's why I took hammers as an example and not guitars. If you care about your specific instrument (not every musician does), then it will stick in the final music, proportionally to the care you give to it. Now, the guy in the audience telling you that he doesn't like your sound may hurt you or not, depending on whether you care about your sound (hence your instrument and the way you play it) or only about the notes you play. But in both cases, the instruments are still here, in the final music.</p> <p>Nobody, on the other hand, can criticize your hammer by looking at your house, or your color brand, by looking at your painting. Although I do understand how one can care about his own hammers (I care about my guitars).</p> <p>I have met musicians that could play with any instrument, with any sound, and still be happy. For them, the instrument truly was only a tool, not personal at all. But this has always puzzled me.</p> Language wars - Alex urn:md5:e96796e88ae6d446c1da10464f94053e 2012-07-12T19:54:55+02:00 2012-07-12T19:50:51+02:00 Alex <p>I was going to remark on the opening string of analogies, too. What's more personal than something you hold in your hand?</p> <p>You might as well say that programming languages are musical instruments, just like a guitar, and there's nothing personal about them -- they just help you play stuff.</p> Language wars - paul urn:md5:efb71f2aed939b7904c7fa96023ad398 2012-07-12T16:44:27+02:00 2012-07-12T16:23:23+02:00 paul <p>Just one nit: I think you're wrong about the hammers. Give me a minute to go through a carpenter's toolkit and I can tell whether I would want to work with them. And you'll sometimes hear people argue one brand or style against another.</p> <p>Of course the other side of that is that criteria for handbuilding of physical structures are fairly straightforward and easily verifiable. If the hammer puts the nails in solidly and in the right places, that's the end of the story in a way that's not so true for software.</p> <p>So it might also be that we have religious wars about languages because we don't actually have hammers, but rather a bunch of different-size, different-shaped rocks, none of which hammers nails very well.</p>