Cómo Persuadir Compradores de eCommerce A Través Del Diseño UX

BY BILAL MOHAMMED - DESIGNER @ TOPTAL (TRANSLATED BY YESICA DANDERFER)

#eCommerce #eCommerceDesign #UX #UXDesign #UXStrategy

Con más de 100 millones de usuarios registrados, 80 millones de productos ofrecidos a través de más de 80 categorías, y aproximadamente 8 millones de envíos hechos por mes, Flipkart—el mercado online más grande de India, comenzaba a perder clientes y experimentar un alto nivel de desinstalaciones de su app. Era claro que el equipo necesitaba pensar en una nueva estrategia para retener a esos clientes, así que rediseñamos la experiencia de usuario de la app de Flipkart.

Era crítico reveer la estrategia de UX y encontrar una solución que se centraría en diseñar una experiencia de usuario que forme hábitos, tener un impato substancial en los usuarios, y generalmente:

• Lograr una conexión más eficiente con los clientes
• Elevar la marca
• Encender el crecimiento

Los compradores online son notoriamente muy conscientes de los precios, y su lealtad es muy breve. La mayor parte del tiempo no les importa de qué sitio compren siempre y cuando obtengan la mejor oferta posible.

Es esencial hacer las siguientes preguntas de forma constante:

• ¿Cómo logras que los consumidores elijan tu eCommerce primero?
• ¿Cómo convences a los compradores que vean tus ofertas antes de compararlas contra tus competidores–que vean precios económicos y luego realizar una compra?

Estos son sólo algunos de los problemas apestando al equipo de product design de UX. Lo que viene a continuación es cómo lidiamos con ello.

Ganar Percepción Haciendo Preguntas Inteligentes

Se volvió obvio que ganar algún tipo de percepción en las opiniones de los consumidores, tendencias y hábitos de compra era crítico para entender el panorama de las compras online, el cual estaba constantemente cambiando, y la capacidad de optimizar la experiencia y satisfacción del cliente.

El equipo de Flipkart continuó preguntándose estas preguntas:

• ¿Cómo construyes una base leal de clientes e incrementar su participación?
• ¿Qué comportamientos deberían ser estudiados para obtener una solución ganadora?
• ¿Cómo construyes una experiencia de compra superior que contiene el instinto de buscar gangas y proveer algo de un valor duradero que haga que los clientes sigan volviendo una y otra vez?
• Y–por último, pero no menos importante–¿Cómo resuelves el problema de las desinstalaciones de la app?

Colaborando con otro Diseñador UX en muchas sesiones de brainstorming, se nos ocurrió un simple propuesta para repensar el UX y hacerlo algo subsequente en el rediseño de la app de Flipkart.

El núcleo de la solución era diseñar una experiencia que forme hábitos que contraste a la experiencia de compra usual de una app de eCommerce.

Pero primero, era necesario reconocer un par de desafíos básicos.

Desafío No. 1: Desinstalaciones de App

Los usuarios mobile tienen una relación frágil con las apps: Aman a algunas pocas que suelen conservar por siempre pero desinstalan a la gran mayoría de ellas que descargan. Voy a compartir un dato sorprendente: el 77% de los usuarios nunca usan una app de nuevo después de 72 horas de haberla instalado. Este porcentaje es un desafío para que los diseñadores hagan que las personas se enamoren con sus apps durante esa crucial primer semana.

Las apps más exitosas son aquellas que tienen un buen diseño conductual–esas apps ‘pegajosas’ que la gente usa de forma regular y no pueden imaginar su vida sin ellas.

Sitios de eCommerce dependenden en eventos de ventas de forma periódica. Estas ventas van desde la categoría de fechas festivas y otras especiales que no son necesariamente por fechas festivas. El “Amazon Prime Day”, por ejemplo, no coincide con ninguna fecha particular o venta anual—como el Black Friday—y sin embargo, Amazon consiguió hacer del Prime Day 2016 el día de compras más exitoso, opacando las ventas del Prime Day 2015 en más del 60% por ciento en todo el mundo.

En 2015, Flipkart vendió productos valuados en $300 millones de dólares durante el “Big Billion Day”, su equivalente de varios días al Amazong Prime Day. Durante la primer hora de venta, Flipkart tenía casi 140 órdenes por segundo. Las descargas de la app mobile de Flipkart suben significativamente cerca del Big Billion Day porque muchas de las ofertas estaban sólo disponibles para compradores a través de la app mobile.

Junto a otras grandes órdenes en el Big Billion Day, vemos una suba en el número de desinstalaciones de apps de forma inmediata a estos eventos. Entre los consumidores que descargaron la app mobile de Flipkart antes o durante el Big Billion Day, en promedio sólo un 30% han dejado al app en sus dispositivos año tras año desde el 2014. Los usuarios suelen dejar de usar la app una vez que las ventas terminan, por lo general debido a problemas de espacio que los Indios tienen en sus dispositivos mobile. (Muchos servicios de telefonía limitan a sus clientes a un total de veinte apps por dispositivo en India). Los consumidores eligen entonces sólo dejar en sus teléfonos las apps que usan de forma diaria, como Facebook, WhatsApp, o YouTube.

Decidimos indagar en profundidad en varias categorías de apps e identificar cuáles son ganadoras y cuáles perdedoras respecto a la lealtad de sus consumidores:

Noticias, Deportes, y el Clima están entre las categorías líderes en la escala de “retención” de usuarios. ¿Por qué? Todas estas apps forman hábitos, o sea, las personas siguen volviendo a ellas una y otra vez. Entonces, para mover su app a la zona de “retención”, Flipkart necesitaba crear una app que formase hábitos.

Pero, ¿qué es una app que forma hábitos? Para saberlo, primero necesitamos identificar los desafíos que enfrenta la lealtad en el eCommerce.

Desafío No. 2: Lealtad Cero

Los hábitos son acciones hechas con poco o nada de pensamiento consciente. Investigaciones sugieren que un 40% de lo que hacemos todos los días es por hábito. Nos enganchamos en hacer cosas de una cierta forma, y nos apoyamos en la consistencia y el confort que nuestros hábitos proveen. Por ejemplo, la industria del video juego ha utilizado concepto de gancho para hacer que sus usuarios vuelvan a jugar sus juegos por años.

La principal forma de “gancho” nos dice que un disparador causa en nosotros realizar una acción por la cual experimentaremos una recompensa. Esa recompensa hace que invirtamos en la acción que nos recompensa, guiándonos a más disparadores y así, perpetuar el ciclo.

No es un secreto que así es como los animales son entrenados.

El gancho comienza con un disparador en el ambiente del usuario. Estamos familiarizados con disparadores externos—por ejemplo, notificaciones sobre productos que nos interesa. Sin embargo, disparadores internos son más críticos en ayudarnos a formar un hábito duradero. Usamos muchas actividades habituales a lo largo del día para escapar de nuestro aburrimiento o, a veces, para salir de un estado emocional negativo y entrar a nuestra zona de confort. Por ejemplo, buscamos en Facebook e Instagram en un intento de mejorar nuestro humor al mirar GIFs animados de cachorritos o videos graciosos de gatos.

FOMO

Cada día cuando nos levantamos, muchos de nosotros sentimos el ‘miedo a perdernos algo’ (o FOMO, fear of missing out). Si revisas tu email, noticias, Facebook, Twitter, etc. ni bien te despiertas por la mañana, entonces ya sabes lo que está sucediendo en el mundo y por eso te sientes más conectado. El equipo de Flipkart vio una oportunidad para utilizar este disparador interno para iniciar su gancho.

La palabra FOMO (fear of missing out) fue de hecho añadida al Diccionario de Inglés de Oxford en el 2013. Aunque la terminología fue sólo recientemente añadida a nuestro léxico, el experimentar FOMO no es nada nuevo.

Para crear un gancho efectivo, necesitarás un patrón de UX viable. Y debes admitir que las notificaciones tradicionales pueden no funcionar bien por sus problemas inherentes; por ej. La ceguera de la notificación.

Flipkart tiene más de 80 millones de productos en más de 80 categorías, así que era importante para ellos categorizar y etiquetar el mar de productos disponibles y mapearlos con los intereses de los usuarios. Lo cual nos lleva al siguiente desafío…

Relevancia y Personalización

Un número de usuarios de Flipkart fueron entrevistados para entender cuándo y cómo compran online de forma general. Se hizo evidente que personalizar una transmisión más corta, con un contenido más pulido y productos relevantes sería más cautivante para ellos. Todos estamos familiarizados en cómo los sistemas de recomendaciones tradicionales funcionan al cristalizar patrones de uso e historia. Pero para Flipkart, esto sólo resolvería parcialmente el problema. Entonces, aprendimos que los usuarios suelen comprar de acuerdo a dos grandes temas:

1. Propósito: Las personas buscan por productos específicos que tienen en mente. Esto mostró que es crítico capturar y tener un seguimiento de las búsquedas de los consumidores de forma individual.
2. Interés: Una conducta mucho más amplia de ‘mirar vidrieras’ y buscar productos en varias categorías que al usuario le guste, o cae dentro de sus intereses. Es mucho más sobre preferencias y tendencias. Por ejemplo, alguien podría tener interés en salud y bienestar, en irse de mochilero, o momentáneamente buscar un regalo de bodas. Flipkart también tuvo como misión capturar esos aspectos de conductas individuales en los consumidores.

• 
• 
• 

Clasificación vs. Temas Interconectados

Para reducir millones de productos en una transmisión de información digerible de un par de productos, necesitábamos pensar muy bien cómo hacer que productos de varias categorías fueran relevantes para un cliente.

Evaluando perfiles de usuarios, observamos que la acción de comprar suele ocurrir en temas. Asignamos un set de meta-etiquetas a cada producto, y con cada etiqueta llegando al punto donde una senda de productos se cruzan, relacionados por tema. En vez de agrupar por categorías y organizar de forma tradicional por clasificación, revisamos nuestro acercamiento y organizamos los productos en temas e historias.

El universo resultante era una combinación de fuertes y holgadas galaxias de productos ligadas e interconectadas—sirviendo como ambos patrones de compra de interés y propósito—que fue construído de forma única para cada usuario. Debajo hay una red para “Viajes”:

El objetivo de la compañía era crear una condición donde, por ejemplo, un cliente pueda ver un producto y explorar productos relacionados en esa historia o tema como si viajara a través de esa galaxia. Este acercamiento le permitió a usuarios ver una colección diversa de productos divididos por su categoría, pero unidos por su historia o tema.

La Solución: Un Resumen Diario y Corto

Internet es grande y muchas veces parece interminable. Los consumidores sofisticados de hoy en día quieren información relevante, no información en abundancia. Esto significó que el motor de las recomendaciones de Flipkart debían ser reconstruidas desde sus cimientos.

Transmisiones Infinitas vs. Finitas

Decidimos construir un resumen diario de un número limitado de productos, actualizando dicho resumen cada día. Esto significó que podíamos movernos de una lista infinita de productos, lo cual por lo general dejaba al usuario en un estado de parálisis de decisión, lo cual se convertía en algo obsoleto y terminaba en algo muy irrelevante y consecuentemente ignorado.

Trabajando El Gancho Para Formar Hábitos Exitosos En La Experiencia De Compra

En el corazón de la solución de Flipkart yace la decisión de usar el concepto del “gancho” para crear una experiencia de usuario que forme hábitos diseñados para atraer a los clientes al sitio de eCommerce.

Sabíamos que los usuarios se apegarían a la anticipación de recibir una potencial recompensa, y por eso se nos ocurrió el concepto del resumen diario, lo cual estaría organizado alrededor de temas e historias, y personalizadas de forma individual para cada usuario.

El camino en el que se apoyó Flipkart para un resumen diario bien diseñado se convirtió en algo bastante familiar con los hábitos existentes de sus clientes. Al entender qué hace que los clientes compren y consuman, y presentarles un número finito de ofertas que Flipkart sabía que serían de su agrado, pudimos tomar ventaja de sus hábitos de compra mobile ya arraigados.

En vez de intentar cambiar los hábitos de los consumidores o convencerlos de los méritos de Flipkart, les dimos un nuevo recurso para agregar a su existentes conductas de FOMO.

Todos en el espacio del eCommerce está compitiendo por un pedazo de lo que se predijo para el 2020 como el mercado global de los $4 trillones de dólares. Las compañías que se equilibraron para salir primeras son aquellas que pensarán exitosamente algo fuera de lo común e implementarán una estrategia en experiencia de usuario diferente de algo más tradicional.

El futuro del eCommerce está atrayendo a clientes con recomendaciones relevantes y personalizadas, construidas alrededor de datos de usuario, y no simplemente sirviendo como un catálogo de productos que empuja al usuario hacia productos que los sitios quieren que compren.

Este articulo fue originalmente posteado en Toptal.

¿Por que hay tantos Pythons?

BY CHARLES MARSH - HEAD OF COMMUNITY @ TOPTAL (TRANSLATED BY PABLO FABREGAT)

#IronPython #Jython #PyPy #Python #RPython #RubyPython

This article was originally written in English

Python es asombroso.

Sorprendentemente, esa es una declaración bastante ambigua. ¿A qué me refiero con ‘Python’?, ¿Me refiero a la interfaz abstracta de Python?, ¿Me refiero a CPython, la implementación común de Python (y no confundir con Cython, que son similares en sus nombres)?, ¿O me refiero a algo completamente distinto? Tal vez me esté refiriendo indirectamente a Jython, o IronPython, o PyPy. O tal vez me he ido al extremo y estoy hablando de RPython o RubyPython (los cuales son cosas muy, muy distintas).

Mientras las tecnologías mencionadas anteriormente son llamadas de formas parecidas y referenciadas de la misma manera, algunas de ellas sirven para propósitos completamente distintos (o, al menos, operan de maneras completamente distintas).

A lo largo de mi tiempo trabajando con Python, me topé con toneladas de estas herramientas .*ython. Pero no hasta hace poco me tomé el tiempo de entender qué es lo que son, cómo funcionan y por qué son necesarias (a sus maneras).

En este artículo, voy a empezar desde cero y recorreré varias implementaciones de Python, concluyendo con una introducción detallada a PyPy, el cual creo es el futuro del lenguaje.

Todo empieza con entender que es lo que ‘Python’ realmente es.

Si tienes un buen entendimiento sobre código binario, máquinas virtuales y parecidos, siéntete libre de saltarte esta parte.

“Python es interpretado o compilado?”

Este es un punto común de confusión para principiantes en Python.

La primera cosa que hay que saber es que ‘Python’ es una interfaz. Existe una especificación sobre lo que Python debería hacer y cómo debería comportarse (cómo con cualquier interfaz). Y hay múltiples implementaciones (como en cualquier interfaz).

Lo segundo que hay que saber es que ‘interpretado’ y ‘compilado’ son propiedades de una implementación, no de una interfaz.

Entonces, la pregunta no está realmente bien formada.

¿Python es interpretado o compilado? La pregunta no está realmente bien formada.

Dicho esto, para la implementación más común (CPython: escrito en C, usualmente llamado simplemente ‘Python’, y seguramente lo que estás usando si no tienes idea de lo que estoy hablando), la respuesta es: interpretado, con algunas partes compiladas. CPython compila** el código fuente de Python a *bytecode, y en ese momento interpreta ese bytecode, ejecutándolo sobre la marcha.

* Nota: no es una ‘compilación’ en sentido tradicional de la palabra. Normalmente, decimos que ‘compilar’ es tomar el código de alto nivel y convertirlo en código binario. Pero es un tipo de ‘compilación’.

Veamos la respuesta un poco más de cerca, ya que nos permitirá entender algunos de los conceptos que surgirán más adelante en el artículo.

Bytecode vs. código binario

Es muy importante entender la diferencia entre bytecode y código binario (o nativo), tal vez mejor ilustrada con ejemplos:

• C compila a código binario, que luego es ejecutado directamente en tu procesador. Cada instrucción le indica a tu CPU que mueva cosas alrededor.
• Java compila a bytecode, que luego es ejecutado en la máquina virtual de Java(Java Virtual Machine, ó JVM), una abstracción de una computadora que ejecuta programas. Cada instrucción es entonces manejada por la JVM, que interactúa con tu computadora.

En términos breves: código binario es más rápido, pero bytecode es más portable y seguro.

El código binario se ve distinto, dependiendo de tu máquina, pero bytecode se ve igual en todas las maquinas. Se podría decir que el código binario está optimizado para tu configuracion.

Volviendo a CPython, el proceso en el conjunto de herramientas sucede de la siguiente manera:

1. CPython compila tu código Python a bytecode
2. Ese bytecode es entonces ejecutado en la Máquina Virtual CPython

Los principiantes asumen que Python es compilado a raíz de los archivos .pyc. Hay alguna verdad en esto: el archivo .pyc es bytecode compilado, que es después interpretado. Entonces si haz ejecutado código Python y ya tienes un archivo .pyc disponible, el mismo va a ejecutarse más rápido la segunda vez ya que no necesitará recompilar el bytecode.

Maquinas virtuales alternativas: Jython, IronPython, y más

Cómo mencioné anteriormente, Python tiene varias implementaciones. De vuelta, como mencioné antes, la más común es CPython. Ésta es una implementación de Python escrita en C y es considerada la implementación ‘por defecto’.

¿Pero, qué pasa con las alternativas? Una de las más prominentes es Jython, una implementación en Java que utiliza la JVM. Mientras CPython produce bytecode para ser corrido en la VM de CPython, Jython produce bytecode de Java para correr en la JVM (esto es lo mismo que es producido cuando se compila un programa en Java).

“¿Por qué usaría alguna vez una implementación alternativa?”, podrías preguntar. Bueno, para empezar, esas diferentes implementaciones juegan muy bien con diferentes conjuntos de tecnologías.

CPython hace muy fácil el escribir extensiones C para tu código Python porque al final es ejecutado por un intérprete de C. Por otro lado, Jython, facilita trabajar con otros programas en Java: puedes importar cualquier clase de Java sin mayor esfuerzo, evocando y utilizando tus clases Java dentro tus programas Jython. (Nota aparte: si no pensaste en esto detalladamente, es una locura. Estamos en un punto donde puedes mezclar y triturar diferentes lenguajes y compilarlos todos en una misma esencia. Como fue mencionado por Rostin, los programas que mezclan código Fortran y C están desde hace un tiempo. Así que, por supuesto que esto no es algo necesariamente nuevo. Pero sigue siendo genial.)

Cómo ejemplo, esto es código Jython válido:

[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_51
>>> from java.util import HashSet
>>> s = HashSet(5)
>>> s.add("Foo")
>>> s.add("Bar")
>>> s
[Foo, Bar]

IronPython es otra implementación popular de Python, escrita enteramente en C# y apuntando a la tecnología .NET. En particular, corre con lo que se podría llamar la Máquina Virtual .NET,Common Language Runtime (CLR)de Microsoft, comparable con la JVM.

Podrías decir que Jython : Java :: IronPython : C#. Corren en sus respectivas VMs, puedes importar clases C# en tu código IronPython y clases Java desde tu código Jython, etc.

Es totalmente posible sobrevivir sin tocar alguna vez una implementación de Python no-CPython. Pero hay ventajas que se obtienen desde el cambio, muchas de ellas son dependientes de la tecnología que uses. ¿Usas muchos lenguajes basados en la JVM? Jython puede ser para tí. ¿Todo lo que haces es sobre la tecnología .NET? Tal vez debas probar IronPython (y tal vez ya lo hayas hecho).

Por cierto: mientras que esto no sería una razón para usar una implementación diferente, nota que estas implementaciones sí difieren en comportamiento más allá de como tratan tu código fuente en Python. Sin embargo, esas diferencias son comúnmente menores, y se disuelven o emergen con el tiempo mientras estas implementaciones se encuentran bajo un activo desarrollo. Por ejemplo, IronPython usa cadenas Unicode por defecto; Sin embargo, CPython, por defecto usa ASCII para versiones 2.x (fallando con un error de codificación UnicodeEncodeError para caracteres no-ASCII), pero sí soporta cadenas Unicode por defecto para las versiones 3.x.

Compilación Justo-a-Tiempo: PyPy y el futuro

Por lo tanto, tenemos una implementación de Python escrita en C, una en Java una en C#. El próximo paso lógico: una implementación de Python escrita en… Python. (El lector educado encontrará esta notación levemente engañosa).

Aquí es donde las cosas se ponen confusas. Primero, discutamos sobre compilación Justo-a-Tiempo (Just-in-Time, ó JIT).

JIT: El por qué y el cómo

Recordemos que el código binario es mucho más rápido que bytecode. Bueno, ¿y si pudiéramos compilar algunas partes de nuestro bytecode y luego correrlo como código nativo? Tendríamos que pagar algún precio al compilar a bytecode (por ej., tiempo), pero si el resultado fuese más rápido, eso sería genial! Esa es la motivación de la compilación JIT, una técnica híbrida que mezcla los beneficios de los interpretadores y los compiladores. En términos básicos, JIT quiere utilizar compilación para acelerar un sistema interpretado.

Por ejemplo, un enfoque común tomado por la compilación JIT:

1. Identificar bytecode que es ejecutado frecuentemente.
2. Compilar a código binario.
3. Almacenar el resultado en memoria caché.
4. Siempre que el mismo bytecode sea encontrado para ejecutar, en vez de usarlo, ejecutar el código binario precompilado y cosechar los beneficios (por ej., aumentos de velocidad)

De esto se trata PyPy: llevar JIT a Python (mira el Apéndice para ver esfuerzos anteriores). Hay, por supuesto, otros objetivos: PyPy apunta a ser multiplataforma, bajo en consumo de memoria e independiente del conjunto de tecnologías. Pero JIT realmente se vende por si solo. Como promedio de un puñado de pruebas de tiempo, se dice que mejora el rendimiento a un factor de 6.27. Para un mayor análisis, véase este cuadro del PyPy Speed Center:

• 
• 
• 

PyPy es difícil de entender

PyPy tiene un gran potencial, y a estas alturas es muy compatible con CPython (así que puede correr Flask, Django, etc.).

Pero hay mucha confusión alrededor de PyPy (véase, por ejemplo, esta propuesta sin sentido para crear un PyPyPy…). En mi opinión, eso es principalmente porque PyPy es actualmente dos cosas:

1. Un intérprete de Python escrito en RPython (no Python (he mentido antes). RPython es un subconjunto de Python con tipos estáticos. En Python, es “prácticamente imposible” razonar rigurosamente acerca de tipos (¿Por que es tan difícil? Bueno, considera el hecho que:

    x = random.choice([1, "foo"])
   

   sería código Python válido (créditos a Ademan). ¿De qué tipo es x? ¿Cómo podemos razonar acerca de tipos de variables cuando los tipos ni siquiera son estrictamente forzados?). Con RPython, sacrificas algo de flexibilidad, pero a cambio es muchísimo más fácil razonar sobre manejo de memoria y demás, lo cual permite optimizaciones.
2. Un compilador que compila código RPython para varios objetivos y agrega JIT. La plataforma por defecto es C, por ej., un compilador RPython-a-C, pero también puedes apuntar a JVM y otros.

Únicamente para mayor claridad, me referiré a ellos como PyPy (1) y PyPy (2).

¿Por qué necesitarías esas dos cosas, y por qué bajo el mismo techo? Piénsalo de esta manera: PyPy(1) es un intérprete escrito en RPython. Entonces toma el código Python del usuario y lo compila a bytecode. Pero el interpretador en sí (escrito en RPython) tiene que ser interpretado por otra implementación de Python para poder correr, ¿Verdad?

Bueno, podríamos simplemente usar CPython para correr el intérprete. Pero eso no sería lo suficientemente rápido.

En cambio, la idea es que usemos PyPy(2) (también conocido cómo RPython Toolchain)-Set de herramientas RPython) para compilar al interpretador de PyPy a código que otra plataforma (por ej., C, JVM o CLI) pueda correr en nuestra máquina, agregando también JIT. Es mágico: PyPy agrega dinámicamente JIT a un interpretador, generando su propio compilador! (De vuelta, esto es una locura: estamos compilando un interpretador y agregando otro compilador independiente por separado).

Al final, el resultado es un ejecutable independiente que interpreta el código fuente Python y explota las optimizaciones de JIT. Que es lo que justamente queríamos! Es un gran bocado, pero tal vez este diagrama ayude:

Reiterando, la verdadera belleza de PyPy es que podemos escribir nosotros mismos un puñado de interpretadores Python distintos en RPython sin preocuparnos por JIT (salvo algunas sugerencias). PyPy entonces implementaría JIT por nosotros usando el set de herramientas de RPython/PyPy(2).

De hecho, si nos ponemos aún más abstractos, podrías, teóricamente, escribir un interpretador para cualquier lenguaje, alimentar a PyPy con él, y obtener un JIT para ese lenguaje. Esto es porque PyPy se enfoca en optimizar el interpretador actual, en vez de los detalles del lenguaje que está interpretando.

Podrías, teóricamente, escribir un interpretador para *cualquier* lenguaje, alimentar a PyPy con él, y obtener un JIT para ese lenguaje.

Divagando un poco, me gustaría mencionar que JIT en sí mismo es absolutamente fascinante. Usa una técnica llamada tracing (ó seguimiento), la cual se ejecuta de la siguiente manera:

1. Correr el interpretador e interpretar todo (sin agregar nada de JIT)
2. Perfilar levemente el código interpretado.
3. Identificar operaciones que hayas realizado antes.
4. Compilar esos pedazos a código binario.

Para más información, este documento es altamente accesible y muy interesante.

Para ir concluyendo: usamos el compilador RPython-a-C de PyPy (u otra plataforma) para compilar el interpretador implementado RPython de PyPy.

Concluyendo

¿Por qué es tan genial? ¿Por qué vale la pena perseguir esta idea tan loca? Creo que Alex Gaynor lo describió muy bien en su blog: “[PyPy es el futuro] porque ofrece mejor velocidad, más flexibilidad y es una mejor plataforma para el crecimiento de Python.”

En resumen:

• Es rápido porque compila código fuente a código nativo (usando JIT).
• Es flexible porque agrega JIT a tu interpretador con muy poco trabajo adicional.
• Es flexible (de nuevo) porque puedes escribir tus interpretadores en RPython, lo cual hace que sea más fácil de extender que, digamos, C de hecho, es tan fácil que hay un tutorial para escribir tus propios intérpretes.

Apéndice: Otros nombres que tal vez hayas oído

• Python 3000 (Py3k): nombre alternativo para Python 3.0, un mayor, compatible-con-versiones-anteriores lanzamiento de Python que alcanzó la escena en 2008. El equipo de Py3k predijo que llevaría alrededor de cinco anos para que esta versión sea completamente adoptada. Y mientras que la mayoría (cuidado: se dice que es anecdótico) de los desarrolladores de Python siguen usando Python 2.x, la conciencia de Py3k entre la gente está incrementándose.

• Cython: un super set de Python que incluye bindings (ó enlaces)para llamar funciones de C.
  • Objetivo: permitirte escribir extensiones en C para tu código Python
  • Además te permite agregar tipos de variables estáticos a tu código Python, permitiéndole que sea compilado y alcanzar rendimiento parecido al de C.
  • Es similar a PyPy, pero no es lo mismo. En este caso, estás forzado a escribir el código del usuario antes de pasarlo al compilador. Con PyPy, escribes simplemente código Python, y el compilador maneja cualquier optimización.

• Numba: : un “compilador especializado justo-a-tiempo” que agrega JIT a código Python anotado. En términos más básicos, le das algunas indicaciones y acelera partes de tu código. Numa viene como parte de la distribución Anaconda,un set de paquetes para manejo y análisis de datos.

• IPython: muy diferente a todo lo que hemos discutido hasta ahora. Es un ambiente de procesamiento para Python. Interactivo y con soporte para herramientas gráficas y experiencia de navegador, etc.

• Psyco: un modulo de extensión de Python, y uno de los primeros esfuerzos de JIT en Python. De todas formas, ha sido marcado como “sin mantenimiento y muerto”. De hecho, el desarrollador principal de Psyco, Armin Rigo, ahora trabaja en PyPy.

Enlaces de lenguaje

• RubyPython: un puente entre las máquinas virtuales de Ruby y Python. Permite embeber código de Python dentro de tu código de Ruby. Defines donde Python comienza y termina, y RubyPython calcula los datos entre las VMs.

• PyObjc: enlaces de lenguaje entre Python y Objetive-C, actuando como un puente entre ellos. Prácticamente, eso significa que puedes utilizar librerías de Objective-C (incluyendo todo lo que necesitas para crear aplicaciones de OS X) desde tu código Python, y módulos de Python desde tu código Objective-C. En este caso, es conveniente que CPython esté escrito en C, el cual es un subconjunto de Objective-C.

• PyQt: mientras PyObjc te ofrece una interfaz para los componentes gráficos de OS X, PyQt hace lo mismo para el framework de QT, permitiendote crear completas interfaces gráficas, acceso a bases de datos SQL, etc. Otra herramienta dirigida a traer la simplicidad de Python a otros frameworks.

Frameworks JavaScript

• pyjs (Pyjamas): un framework para crear aplicaciones web y de escritorio en Python. Incluye un compilador Python-a-Javascript, un conjunto de widgets, y algunas herramientas más.

• Brython: una máquina virtual de Python escrita en JavaScript para permitir que el código de Py3k sea ejecutado en navegadores.

Contenido traducido por Pablo Fabregat, miembro de TransBunko, un mercado de traducciones técnicas.

Este articulo fue originalmente publicado en Toptal.