<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments for /var/log/prakti</title>
	<atom:link href="http://www.prakti.org/~myself/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.prakti.org/~myself</link>
	<description>Hacks and the City</description>
	<pubDate>Wed, 10 Mar 2010 00:29:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>Comment on Collectible Certificates by Alexander Schremmer</title>
		<link>http://www.prakti.org/~myself/2008/11/14/collectible-certificates/#comment-6983</link>
		<dc:creator>Alexander Schremmer</dc:creator>
		<pubDate>Sat, 15 Nov 2008 10:02:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.prakti.org/~myself/?p=91#comment-6983</guid>
		<description>Don Knuth has an interesting opinion in this regard as well:

"""
I always thought that the best way to sum up my professional work is that it has been an almost equal mix of theory and practice. The theory I do gives me the vocabulary and the ways to do practical things that can make giant steps instead of small steps when I'm doing a practical problem. The practice I do makes me able to consider better and more robust theories, theories that are richer than if they're just purely inspired by other theories. There's this symbiotic relationship between those things. At least four times in my life when I was asked to give a kind of philosophical talk about the way I look at my professional work, the title was "Theory and Practice." My main message to the theorists is, "Your life is only half there unless you also get nurtured by practical work."

Software is hard. My experience with TeX taught me to have much more admiration for colleagues that are devoting most of their life to software than I had previously done, because I didn't realize how much more bandwidth of my brain was being taken up by that work than it was when I was doing just theoretical work.

"""

Communications of the ACM, Volume 51, Number 8 (2008), Pages 31-35

http://portal.acm.org/ft_gateway.cfm?id=1378715&#38;type=html&#38;coll=portal&#38;dl=ACM&#38;CFID=://cacm.acm.org/communications?pageIndex=3&#38;CFTOKEN=cacm.acm.org/communications?pageIndex=3</description>
		<content:encoded><![CDATA[<p>Don Knuth has an interesting opinion in this regard as well:</p>
<p>&#8220;&#8221;"<br />
I always thought that the best way to sum up my professional work is that it has been an almost equal mix of theory and practice. The theory I do gives me the vocabulary and the ways to do practical things that can make giant steps instead of small steps when I&#8217;m doing a practical problem. The practice I do makes me able to consider better and more robust theories, theories that are richer than if they&#8217;re just purely inspired by other theories. There&#8217;s this symbiotic relationship between those things. At least four times in my life when I was asked to give a kind of philosophical talk about the way I look at my professional work, the title was &#8220;Theory and Practice.&#8221; My main message to the theorists is, &#8220;Your life is only half there unless you also get nurtured by practical work.&#8221;</p>
<p>Software is hard. My experience with TeX taught me to have much more admiration for colleagues that are devoting most of their life to software than I had previously done, because I didn&#8217;t realize how much more bandwidth of my brain was being taken up by that work than it was when I was doing just theoretical work.</p>
<p>&#8220;&#8221;"</p>
<p>Communications of the ACM, Volume 51, Number 8 (2008), Pages 31-35</p>
<p><a href="http://portal.acm.org/ft_gateway.cfm?id=1378715&amp;type=html&amp;coll=portal&amp;dl=ACM&amp;CFID=://cacm.acm.org/communications?pageIndex=3&amp;CFTOKEN=cacm.acm.org/communications?pageIndex=3" rel="nofollow">http://portal.acm.org/ft_gateway.cfm?id=1378715&amp;type=html&amp;coll=portal&amp;dl=ACM&amp;CFID=://cacm.acm.org/communications?pageIndex=3&amp;CFTOKEN=cacm.acm.org/communications?pageIndex=3</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Howto backport ClamAV in Debian Etch (stable) by jimbob</title>
		<link>http://www.prakti.org/~myself/2007/12/29/howto-backport-clamav-daemon-in-debian-etch-unstable/#comment-6871</link>
		<dc:creator>jimbob</dc:creator>
		<pubDate>Sat, 18 Oct 2008 09:11:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.prakti.org/~myself/2007/12/29/howto-backport-clamav-daemon-in-debian-etch-unstable/#comment-6871</guid>
		<description>Thanks, it worked.</description>
		<content:encoded><![CDATA[<p>Thanks, it worked.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Optimization in Python by Prakti</title>
		<link>http://www.prakti.org/~myself/2008/09/13/optimization-in-python/#comment-6755</link>
		<dc:creator>Prakti</dc:creator>
		<pubDate>Thu, 25 Sep 2008 00:49:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.prakti.org/~myself/2008/09/13/optimization-in-python/#comment-6755</guid>
		<description>Psyco is a nice idea and upon the suggestion I tried to integrate it into my experiment, but if I create a proxy for the sieve4 function, this proxy is invisible to all profilers. Thus, a significant comparison needs a completely new approach. Any ideas are welcome.

&lt;a href="http://www.prakti.org/~myself/files/sieve-of-erastosthenes.tar.bz2" rel="nofollow"&gt;Here&lt;/a&gt; is the source-code for my experiment if anyone wants to work with it.</description>
		<content:encoded><![CDATA[<p>Psyco is a nice idea and upon the suggestion I tried to integrate it into my experiment, but if I create a proxy for the sieve4 function, this proxy is invisible to all profilers. Thus, a significant comparison needs a completely new approach. Any ideas are welcome.</p>
<p><a href="http://www.prakti.org/~myself/files/sieve-of-erastosthenes.tar.bz2" rel="nofollow">Here</a> is the source-code for my experiment if anyone wants to work with it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Optimization in Python by Paddy3118</title>
		<link>http://www.prakti.org/~myself/2008/09/13/optimization-in-python/#comment-6702</link>
		<dc:creator>Paddy3118</dc:creator>
		<pubDate>Sat, 13 Sep 2008 12:41:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.prakti.org/~myself/2008/09/13/optimization-in-python/#comment-6702</guid>
		<description>&lt;a href="http://psyco.sourceforge.net/" rel="nofollow"&gt;Psyco&lt;/a&gt;?

- Paddy.</description>
		<content:encoded><![CDATA[<p><a href="http://psyco.sourceforge.net/" rel="nofollow">Psyco</a>?</p>
<p>- Paddy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on pushing Bits by Dirk Meister</title>
		<link>http://www.prakti.org/~myself/2006/11/15/pushing-bits/#comment-5387</link>
		<dc:creator>Dirk Meister</dc:creator>
		<pubDate>Wed, 02 Apr 2008 09:02:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.prakti.org/~myself/2006/11/15/pushing-bits/#comment-5387</guid>
		<description>Die BegrÃ¼ndung ist relativ einfach. Bei Java wurde sehr stark darauf geachtet, dass die VM von der Hardware-Architektur abgekapselt ist. Ein cast nach byte[] wurde die Objektdarstellung von der Hardware (Big-Endian, Little-Endian, 64bit/32bit, Byte Alignment, etc.) abhÃ¤ngig machen.

AuÃŸerdem ist bei der Entwicklung von Java auf die Typsicherheit in dem Sinne geachtet worden, dass keine ungÃ¼ltigen Objekte (Wild Pointer etc) erzeugt werden. Bei dem Weg Object x = (Object)byteArray kÃ¶nnte dies aber leicht passieren. Deshalb sind in Java nur Casts zwischen mÃ¶glicherweise kompatiblen Typen erlaubt. Aber so einfach ist es ja auch bei Python's struct nicht.

Der Defaultweg um Java-Objekte zu serialisien (fÃ¼r ein Flat-File, oder Netzwerklink) ist das java.io.Serializable Interface. Aber damit wird die On-the-Wire-ReprÃ¤sentierung automatisch festgelegt. Mit java.io. Externalizable hast du schon eine ziemlich genau kontrolle Ã¼ber die ReprÃ¤sentierung. Overhead fÃ¼r den Programmierer hat man so kaum (bei Serializable kann man einfach die Default-ReprÃ¤sentierung nehmen), Overhead auf dem Wire ist definitiv vorhanden (z.B. schreibt Java automatisch bestimmte Klasseninformationen, um sicher zustellen, dass die originale Klasse kompatibel ist mit der Version der Klasse am anderen Ende der Leitung), aber i.d.R. wird es als effizient genug betrachtet.</description>
		<content:encoded><![CDATA[<p>Die BegrÃ¼ndung ist relativ einfach. Bei Java wurde sehr stark darauf geachtet, dass die VM von der Hardware-Architektur abgekapselt ist. Ein cast nach byte[] wurde die Objektdarstellung von der Hardware (Big-Endian, Little-Endian, 64bit/32bit, Byte Alignment, etc.) abhÃ¤ngig machen.</p>
<p>AuÃŸerdem ist bei der Entwicklung von Java auf die Typsicherheit in dem Sinne geachtet worden, dass keine ungÃ¼ltigen Objekte (Wild Pointer etc) erzeugt werden. Bei dem Weg Object x = (Object)byteArray kÃ¶nnte dies aber leicht passieren. Deshalb sind in Java nur Casts zwischen mÃ¶glicherweise kompatiblen Typen erlaubt. Aber so einfach ist es ja auch bei Python&#8217;s struct nicht.</p>
<p>Der Defaultweg um Java-Objekte zu serialisien (fÃ¼r ein Flat-File, oder Netzwerklink) ist das java.io.Serializable Interface. Aber damit wird die On-the-Wire-ReprÃ¤sentierung automatisch festgelegt. Mit java.io. Externalizable hast du schon eine ziemlich genau kontrolle Ã¼ber die ReprÃ¤sentierung. Overhead fÃ¼r den Programmierer hat man so kaum (bei Serializable kann man einfach die Default-ReprÃ¤sentierung nehmen), Overhead auf dem Wire ist definitiv vorhanden (z.B. schreibt Java automatisch bestimmte Klasseninformationen, um sicher zustellen, dass die originale Klasse kompatibel ist mit der Version der Klasse am anderen Ende der Leitung), aber i.d.R. wird es als effizient genug betrachtet.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
