<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Compilers on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/compilers/</link><description>Recent content in Compilers on Karpoke - Just Another Blog</description><generator>Hugo -- 0.167.0</generator><language>es</language><lastBuildDate>Thu, 02 Dec 2021 13:03:41 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/compilers/index.xml" rel="self" type="application/rss+xml"/><item><title>The Abstract Syntax Tree</title><link>http://karpoke.ignaciocano.com/2021/12/02/the-abstract-syntax-tree/</link><pubDate>Thu, 02 Dec 2021 13:03:41 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2021/12/02/the-abstract-syntax-tree/</guid><description>&lt;blockquote&gt;
&lt;p&gt;Introduction One of the first steps a compiler must take is parse the
human-readable&amp;hellip;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;» DEV Community | &lt;a href="https://dev.to/drbearhands/the-abstract-syntax-tree-1p30"&gt;dev.to&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Reflections on Trusting Trust</title><link>http://karpoke.ignaciocano.com/2014/08/15/reflections-on-trusting-trust/</link><pubDate>Fri, 15 Aug 2014 08:05:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2014/08/15/reflections-on-trusting-trust/</guid><description>&lt;blockquote&gt;
&lt;p&gt;You can’t trust code that you did not totally create yourself.
(Especially code from companies that employ people like me.) No amount
of source-level verification or scrutiny will protect you from using
untrusted code. In demonstrating the possibility of this kind of
attack, I picked on the C compiler. I could have picked on any
program-handling program such as an assembler, a loader, or even
hardware microcode. As the level of program gets lower, these bugs
will be harder and harder to detect. A well installed microcode bug
will be almost impossible to detect.&lt;/p&gt;
&lt;/blockquote&gt;</description></item><item><title>Why Java is a compiled language and Python is not</title><link>http://karpoke.ignaciocano.com/2014/05/24/why-java-is-a-compiled-language-and-python-is-not/</link><pubDate>Sat, 24 May 2014 07:36:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2014/05/24/why-java-is-a-compiled-language-and-python-is-not/</guid><description>&lt;blockquote&gt;
&lt;p&gt;One comment’s answer was ’marketing’, which in a sense is correct; one
reason we call Java a compiled language is that that’s what Sun called
it from the start. Another comment noted that Java has an explicit
compilation phase that is separate from having the JVM execute your
Java program by interpreting the bytecodes. All of this points us
towards what I feel is the real answer:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;In Java, bytecode is a first class object. In Python it’s an
internal implementation detail.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;/blockquote&gt;</description></item></channel></rss>