Creando mi propio lenguaje: Ideas

[mamcx]

Me pico el bicho de crear un lenguaje de programacion. No he podido sacarme de la cabeza la idea a pesar de que:

1- Ya hay demasiados
2- Es una tarea titanica
3- Es casi imposible que resulte exitoso
4- No tengo el tiempo ni los recursos

Pero en fin. No es secreto que me encanta python, asi que no es sopresa que esta basado en el. Pero estas son un conjunto de ideas que me *fastidian enormemente* cuando programo, y me gustaria que existiera el lenguaje que propongo.

Filosofia (ideas en desorden)

100% de acuerdo con Zen de Python.

Muerte al NULL. Me da rabia de la mala (en especial con Ojb-c) que un objeto puede ser NULL en cualquier momento y que cause un error de excepcion. Por ende, mi lenguaje no considera que el valor de inicializacion de todo es un NULL. Todo se inicializa y existe legalmente, y no se puede nulificar (a menos que se use un tipo nullable). El NULL es un caso excepcional, pero casi todos los lenguajes lo consideran el estado por defecto. NULL es como tener que manejar la memoria manualmente...

Dentro del programa, solo existe UNA y SOLO una forma de formato de datos. No veo porque deba usarse "\" o "/" en un lenguaje para manejar el separador de carpetas, porque existe simultaneamente cadenas ASCII, utf(8, 16, 32) y demas a la vez. O que haya la posibilidad de tener varios formatos de fecha, basados en la configuracion regional.

En mi opinion, el mundo exterior no debe alterar el comportamiento del interior del programa. El programa lee y transforma en los datos para ser compatible con el mundo exterior (ej: Para mostrarle al usuario, o al leer campos de tablas, configuracion del sistema) pero una vez esta dentro del sistema, no existe variacion en la estructura de datos.

La unidad basica es la funcion, no el objeto. Esto combina con:

No hay necesidad de usar herencia para la OO. 100% de acuerdo con GO.

Los numeros se hace con tipos de datos DECIMAL, no integrales o flotantes. Es toda una patada que las operaciones de +,-.* funcionen bien pero las / salgan incorrectas. La matematica DECIMAL no tiene problemas de errores de precision. El uso de INT y FLOAT se debe relegar a los casos donde tiene sentido.

Los string deben ser internamente por defecto UTF8.

Los mensajes de error deben tener los datos!!! Me *mata" cuando hay un mensaje del tipo " El registro esta duplicado". Y no me dice: En que tabla de que BD, de que campo, y lo mas importante, que VALOR lanzo el problema! Deberia ser: "El registro en Clientes.Id = 1 esta duplicado"

Todo esto se puede resumir en: por defecto, lo correcto/obvio no lo mas eficiente. Usar el principio de la menor sorpresa.

Como se veria el lenguaje?

Variables. Seria un lenguaje tipado, como PASCAL

Código PHP:

# Comentario
int: Int32 #Inicializa en 0
int: Int64 #Inicializa en 0
int: Float #Inicializa en 0.0
num: Num #Inicializa en 0.0, tipo DECIMAL y por defecto
name: Str # UTf8
IsTrue: Bool #Inicializa en false
today: Date = 2002-08-10  #Inicializa en 0000-00-00
hour: Hour = 10:00:00 #24 H format  #Inicializa en 00:00:00
todayHoue: DateTime = 2002-08-10-10:00:00
path: Path = /root  #Inicializa en /
range: [1..2]  #Se debe incializar explicitamente

data: Dict = {num:name}  #Inicializa en {}
dataTyped: Dict<Number,String> = {num:name}
things: List = [num, name, IsTrue] #Inicializa en []
thingsTyped: List<String> = [name]
error?: ERROR #Marca con ? que la vble es nullable. Inicializa en NULL 


Constantes se diferencian porque estan todo en mayuscula:

Código PHP:

PI = 3.1416 


Control:

Código PHP:

for thing in things:
    print(thing)

for i in range(1,10):
    print(i)

for IsTrue: #Reemplaza while.
    print("Yep forever!")

    break

for: #While forecer
    print("Infinite!")

if IsTrue:
    print("Yep") 


Al igual que GO, creo que while es un caso poco usual si las clases se trabajan como enumeradores, asi que no justifica tener un comando aparte.

Texto largo. Soporte a closure, asi que captura las vbles/funciones de su entorno. No hay comillas!

Código PHP:

"""
    Just text [IsTrue]. LLama [funcion()]
""" 


Funciones. Si empieza por "_" es privado, de lo contrario publico. Bloque para declarar vbles y parametros. Me parece mas legible que con (param1:Str,param1:Str,param1:Str,param1:Str,param1:Str,param1:Str,)

Código PHP:

#Private function
def _sample:
    print("hi")

#Public function with return value
def sample : String
var:
    IsOk:Bool
body: 
    return "hi"

#Public function with multiple return values
def sample : Str, Error?
input:
    param1:Str
    param2:Number
    params: *List
body:
    return text:
        Hola [param1] [param2] [params]
    None 


Clases:

Código PHP:

class Person:
    name:Str

    def print: Str
    text:
        Documentacion
    input:
        times:Int32
    body:
        for i in range(1,times):
            print(self.name)
#Herencia
class Moderator:
    embed: Person

mamcx = Moderator()

mamcx.print() #Los metodos de Person se invocan. Pero no existe herencia 


Una de las ideas que me dan vueltas y vueltas, y que tiene que ver con el concepto de mantener integridad en los datos una vez estan en el universo interior, lo llamo PowerType y esta basado en como se define un campo en una tabla.

Por ejemplo:

Código SQL [-]
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price > 0)
);

La idea es que el tipo de datos hace la transformacion y el validado del dato en el mismo tipo.

Esto es lo que tengo por ahora:

Código PHP:

#PowerType

type Mayuscula:Str
    #Ejecuta al asignar el valor
    def transform: Str
        return self.raw.toUpper()

    def require:Bool,Error?
        return assert(len(self.value)>0, Error("[self.name] no puede estar vacio")

miNombre:Mayuscula = "mario"
print(miNombre)
>> MARIO

miNombre = "" #Genera error: miNombre no puede estar vacio 

#Funcion con PowerType

def sample:
input:
    nombre:Mayuscula
body: 
    print(nombre)

sample("") #Genera error: nombre no puede estar vacio 


P.D: Esto todavia no esta MUY bien pensado. Criticas, sugerencias?

[TiammatMX]

Empezado por mamcx

...P.D: Esto todavia no esta MUY bien pensado. Criticas, sugerencias?

No sabes..., sería TAN hermoso un lenguaje de programación "PASCAL alike" en castellano...

En la profesional nos tocó "diseñar" un compilador para una materia de programación, pero como en todos los casos, terminas recurriendo a C para "crear" tu lenguaje. Como dato curioso, nuestro lenguaje de programación usaba el náhuatl como modelo de sintaxis y en las palabras.

[dec]

¡No te desanimes porque alguien como yo no pueda decir esta boca es mía aquí y ahora!

[LoPiTaL]

Hola! Antes que nada, mi intención no es desanimar Me parece muy interesante tu planteamiento, y con un lenguaje así, podrías resolver muchos problemas de una forma muy sencilla.

Pero...

Muerte al NULL. Me da rabia de la mala (en especial con Ojb-c) que un objeto puede ser NULL en cualquier momento y que cause un error de excepcion. Por ende, mi lenguaje no considera que el valor de inicializacion de todo es un NULL. Todo se inicializa y existe legalmente, y no se puede nulificar (a menos que se use un tipo nullable). El NULL es un caso excepcional, pero casi todos los lenguajes lo consideran el estado por defecto. NULL es como tener que manejar la memoria manualmente...

A nadie nos gusta el NULL. Sin embargo, existe por obligación, no por necesidad. Tal como planteas, tu RTL debería comprobar cada vez que se asigna un valor a una variable objeto si éste es NULL o no y lanzar una excepción. Esto consume infinidad de recursos, volviendo la aplicación lenta (de hecho FastMM te advierte cuando activas esta opción que tu programa podría volverse lento).

Dentro del programa, solo existe UNA y SOLO una forma de formato de datos. No veo porque deba usarse "\" o "/" en un lenguaje para manejar el separador de carpetas, porque existe simultaneamente cadenas ASCII, utf(8, 16, 32) y demas a la vez. O que haya la posibilidad de tener varios formatos de fecha, basados en la configuracion regional.

Esto corrobora tu 3ª hipótesis ("Es casi imposible que resulte exitoso") ya que de un plumazo te has eliminado TODAS las aplicaciones que no sean de bases de datos ni muy sencillas. P. ej., si alguien sólo quiere ASCII porque es infinitamente más rápido que UTF, ese programador ya no elegirá tu aplicación. Lo mismo con Integer e int64; y con Float, double y extended (hablando de los tipos en Delphi). También te quitas todos los que estén en el otro extremo, que necesiten mucha precisión y no tengan acceso a tipos de datos de más de 4 bytes.

No hay necesidad de usar herencia para la OO

Esto es cierto, sin embargo la mayoría de lenguajes actuales ya ofrecen alguna implementación de objetos agregados: p. ej. en Delphi mediante interfaces definidas a través de "implements"

Los numeros se hace con tipos de datos DECIMAL, no integrales o flotantes. Es toda una patada que las operaciones de +,-.* funcionen bien pero las / salgan incorrectas. La matematica DECIMAL no tiene problemas de errores de precision. El uso de INT y FLOAT se debe relegar a los casos donde tiene sentido.

Los string deben ser internamente por defecto UTF8.

Esto es más de lo de antes, vuelves la aplicación lenta y sin opción a que los desarrolladores elijan.

Los mensajes de error deben tener los datos!!! Me *mata" cuando hay un mensaje del tipo " El registro esta duplicado". Y no me dice: En que tabla de que BD, de que campo, y lo mas importante, que VALOR lanzo el problema! Deberia ser: "El registro en Clientes.Id = 1 esta duplicado"

Esto es totalmente correcto! Pero esto es problema del programador, no del lenguaje: p. ej. raise Exception.Create('Error en dirección $FFFFF!') frente a Exception.Create('Se ha leido una variable que era NULL dentro del procedimiento MiMétodo que lo he metido en la unit LaUnit.pas').

Todo esto se puede resumir en: por defecto, lo correcto/obvio no lo mas eficiente. Usar el principio de la menor sorpresa.

Después de todo lo comentado, esto es lo que saldría del lenguaje. Lo que me parece la verdad muy interesante a pesar de todo.
Sin embargo, lo vería más como un lenguaje para aprendizaje, con las opciones limitadas, todo fuertemente tipado y sin posibilidad de errores; más que para un lenguaje profesional, donde las necesidades de cada uno son muy diversas y no se pueden englobar en un lenguaje con las características que propones. Sin embargo, ya digo, como lenguaje para iniciación me parece muy bien.

Un saludo, y espero no haberte desanimado
LoPiTaL

[mamcx]

Empezado por LoPiTaL

Hola! Antes que nada, mi intención no es desanimar Me parece muy interesante tu planteamiento, y con un lenguaje así, podrías resolver muchos problemas de una forma muy sencilla.

Diseñar un lenguaje es mas dificil que usarlo. Como todo programa, es un balance de cosas que pueden ser opuestas (por ejemplo rapido <> pequeño en memoria).

Adicionalmente, si se va a hacer un lenguaje ligeramente parecido a otro, pues como que no tiene mucha gracia!

Se que ciertas decisiones pueden afectar el desempeño (hipotetico, porque no lo he probado) de este lenguaje. Lo que interesa es saber si perder X se compensa con creces con ganar Y.

Por ejemplo, al usar un recolector de basura se afecta el rendimiento a bajo nivel, pero se compensa con una mayor productividad y simplicidad en el codigo.

Lo malo es que se pierda X y lo que se obtiene Y es tan miserable que no valio la pena.

Empezado por LoPiTaL

Tal como planteas, tu RTL debería comprobar cada vez que se asigna un valor a una variable objeto si éste es NULL o no y lanzar una excepción.

Porque debo hacer la comparacion en cada momento? Eso es lo que quiero evitar! que exista la necesidad de hacer:

Código PHP:

if obj is None:
   print "Invalido" 


Cuando el NULL es el estado de inicializacion por defecto, y se puede asignar NULL a cada cosa en cualquier momento, esos chequeos tienen sentido. Pero si el lenguaje simplemente no lo permite NULL, es identico a hacer un chequeo de tipos:

Código PHP:

name:String
lastName:Date

print name + lastName #Saca error 


Esto se puede comprobar al momento de la compilacion si el lenguaje es tipado.

Algunas lecturas que me han convencido:

http://programmers.stackexchange.com...ly-a-bad-thing

http://lambda-the-ultimate.org/node/2699

An enormous advantage of this is that it allows the type system to statically enforce & check correct usage of nullable values, essentially eliminating "null pointer exception" errors or the equivalent.

El problema en cambio, se daria en un lenguaje de tipos dinamicos, donde una variable puede ser de cualquier tipo (potencialmente null) y ahi si podria caber el problema que mencionas

Empezado por LoPiTaL

P. ej., si alguien sólo quiere ASCII porque es infinitamente más rápido que UTF, ese programador ya no elegirá tu aplicación. Lo mismo con Integer e int64; y con Float, double y extended (hablando de los tipos en Delphi). También te quitas todos los que estén en el otro extremo, que necesiten mucha precisión y no tengan acceso a tipos de datos de más de 4 bytes.

No es mi intencion eliminar la posibilidad de elegir otros tipos de datos y/o estructuras mas adecuadas segun el caso, sino presentar como "defecto" la opcion mas "sana" posible, que da pocas sorpresas.

Es mi opinion que es mejor disponer de la opcion mas sana a costa de una potencial degradacion en desempeño para la mayoria de los casos, y elegir la opcion mas eficiente para cuando se necesite, que tener la opcion mas "problematica" por defecto todo el tiempo, y tener que estar chequeando las cosas.

Eso es una lata impresionante. Por ejemplo, en python 3 movieron todo a UTF en las cadenas. Una de las razones, es que cuando se hace apps web TODO EL MALDITO TIEMPO surge el error Unicode decode error.

Lo malo es que sale en algo tan simple como:

Código PHP:

>>> "ñ" + u"a"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in range(128) 


Que es algo que no necesita el maximo desempeño.

Yo cambio milisegundos en la ejecucion del programa contra horas de depuracion.

Lo que indico con la representacion interna es que haya una forma estable y bien delineada de como se mueven los datos, y que se convierta de forma explicita una vez que se toca el mundo exterior.

Esto es más de lo de antes, vuelves la aplicación lenta y sin opción a que los desarrolladores elijan.

No he desechado los tipos Float/Int!

Simplemente considero que no tiene presentacion que :

Código PHP:

1.1 + 2.2
>>>3.3000000000000003
>>> (1.1 + 2.2) == 3.3
False 


Esto es una aberracion. El computador no sabe matematicas!. En cambio el tipo decimal:

Decimal “is based on a floating-point model which was designed with people in mind, and necessarily has a paramount guiding principle – computers must provide an arithmetic that works in the same way as the arithmetic that people learn at school.” – excerpt from the decimal arithmetic specification.

El problema del desempeño podria darse si se esta decodificando una imagen, haciendo calculos complejos, criptografia, etc. Pero en mi experiencia, la mayoria de las veces que se usa un numero en un programa es para:

-Indicar un valor: Edad=18
-Contadores
-Calculos aritmeticos elementales: Total = SubTotal + (SubTotal * (Impuesto/100)) - Descuento

Los problemas de desempeño se verian en ciclos cerrados, o en tareas especializadas, donde el programador debe estar mas consiente de lo que hacer.

Empezado por LoPiTaL

Sin embargo, lo vería más como un lenguaje para aprendizaje, con las opciones limitadas, todo fuertemente tipado y sin posibilidad de errores; más que para un lenguaje profesional, donde las necesidades de cada uno son muy diversas y no se pueden englobar en un lenguaje con las características que propones.

Mientras todavia este lenguaje es apenas una idea (que ni se si vera la luz del dia) me parece extraño que consideres que un lenguaje "fuertemente tipado y sin posibilidad de errores" es contrario a "un lenguaje profesional". Un ejemplo notable es haskell que es reconocido por hacer software tremendamente estable, correcto y robusto (principalmente, a que tiene el manejo de tipos mas tremendo que existe). O Erlang que es el unico lenguaje -del que se- lo suficientemente robusto para manejar MILLONES de tareas concurrentes en un SOLO equipo, y se puede reemplazar -modificar a si mismo o por recarga- mientras esta en ejecuccion y sin sacar errores!

Obviamente, si es mas importante la velocidad de la maquina, C o Assembler. Pero creo que casi todos los lenguajes estan diseñados para acelerar al desarrollador...

[[Delphius]]

Empezado por tiammat

No sabes..., sería TAN hermoso un lenguaje de programación "PASCAL alike" en castellano...

Si que existe.
Como también existe un SO (bueno... en realidad sólo es un kernel) llamado Toro, hecho en Pascal, Free-Pascal para ser más preciso.
Ambos proyectos nacidos en mi tierra, lástima que casi completamente parados

Y luego algunos fanáticos anti-Pascal dicen que Pascal es sólo para enseñar

Saludos,

[LoPiTaL]

me parece extraño que consideres que un lenguaje "fuertemente tipado y sin posibilidad de errores" es contrario a "un lenguaje profesional"

No me he expresado bien. Con "fuertemente tipado" me refería a que el programador está obligado a usar un único tipo de datos, y a lo de "sin posibilidad de errores" a lo de la no existencia de NULL.

Si como dices, no obligas al programador a usar un tipo único, sino que sigues permitiendo la elección (lo cual no quedaba claro en tu primer mensaje), entonces retiro esta objeción.

En cuanto a lo del NULL, no había visto nunca la discusión que indicas en los links, aunque después de revisarlos, veo que básicamente Haskell utiliza lo que dices de tipos nullables, que al fin y al cabo, para utilizarlos, tienes que hacer una comparación con NULL (paso de parámetro nullable con "Maybe t", entonces para poder usarlo tienes que usar "Just x", el cual comprueba si es NULL y te lanza excepción). La diferencia es si no pasas un "Maybe t", sino sólo "t", con el cual estás seguro que no es NULL... no sé, Haskell acaba de meterse en mi lista de TODOs

Supongo que así sí que podría resultar un lenguaje profesional.
Espero novedades sobre el lenguaje

Un saludo,
LoPiTaL

PD: ¿tienes ya nombre para él?

[Casimiro Notevi]

Empezado por mamcx

No he desechado los tipos Float/Int!
Simplemente considero que no tiene presentacion que :

Código PHP:

1.1 + 2.2
>>>3.3000000000000003
>>> (1.1 + 2.2) == 3.3
False 


Esto es una aberracion. El computador no sabe matematicas!. En cambio el tipo decimal:
El problema del desempeño podria darse si se esta decodificando una imagen, haciendo calculos complejos, criptografia, etc. Pero en mi experiencia, la mayoria de las veces que se usa un numero en un programa es para:
-Indicar un valor: Edad=18
-Contadores
-Calculos aritmeticos elementales: Total = SubTotal + (SubTotal * (Impuesto/100)) - Descuento
Los problemas de desempeño se verian en ciclos cerrados, o en tareas especializadas, donde el programador debe estar mas consiente de lo que hacer.

En eso tienes razón.

Empezado por Delphius

Si que existe. Como también existe un SO (bueno... en realidad sólo es un kernel) llamado Toro, hecho en Pascal, Free-Pascal para ser más preciso.

Una pena que proyectos así se pierdan.

[mamcx]

Tener soporte para proyectos latinos por latinos es bien dificil, no hay el mismo "espiritu" y la falta de recursos golpea bastante.

----

Aun no le tengo nombre. Estoy recaudando informacion para ver que tan dificil es sacar una version 0.1 y tengo muchas lagunas. Por ahora trato es de imaginarme la sintaxis y como seria trabajar con el.

----

Otra cosa que me gustaria es poder instrumentar el codigo de forma nativa, pero desacoplada. Por ejemplo, para facilitar depuracion y/o analisis de velocidad y desempeño.

Asi como se puede hacer un evento OnClick para escuchar un click del usuario:

Código PHP:

#Function hook

def startDef:
    self.cache['start'] = now

def endDef:
    performance.register(self.function.__name,'time', now - self.cache['start'])

hook(sample,pre = startDef, post = endDef) 


La idea es que se pueda capturar funciones/clases y poner escucha a la entrada/salida, como si fuera triggers de la BD, pero que no requieren ser escritos a mano o decarar manualmente cada metodo a instrumentar.

Junto a eso, imagino seria muy util poder capturar remotamente una sesion de depuracion. Y poder, por ejemplo, logear los datos de entrada/salida de las funciones y poder marcar cuando X valor pasa (para detectar un error).

El chiste es que la instrumentacion sea dinamica:

Código PHP:

#Instrument

server= instrument.Attach('/c:/Proyecto/Programa.exe', ApiKey= '****')

server.hook(sample,pre = startDef, post = endDef)

print performance 


[donald shimoda]

Empezado por Delphius

Si que existe.
Como también existe un SO (bueno... en realidad sólo es un kernel) llamado Toro, hecho en Pascal, Free-Pascal para ser más preciso.

Saludos,

Que bueno lo de Toro, como experiencia académica es excelente, me saco el sombrero!

[[Delphius]]

Empezado por donald shimoda

Que bueno lo de Toro, como experiencia académica es excelente, me saco el sombrero!

Yo escuché sobre Toro y Matías Vara en los últimos años de la facultad, aunque ahora tengo la ligera sospecha de que a mediados de cursado me lo he "encontrado" en la 33 JAIIO en el 2004; antes de que el proyecto cambiara de rumbo.
No recuerdo bien que TORO Kernel (ex TORO OS) sea parte de su proyecto final para el título. Si en cambio que fue de inspiración académica. Si en verdad Matías Vara está haciendo este proyecto por el título, ¡que alguien le haga recordar mi experiencia! ¡Que no se meta en chaleco de 11 balas!

Saludos,

[donald shimoda]

Empezado por Delphius

Yo escuché sobre Toro y Matías Vara en los últimos años de la facultad, aunque ahora tengo la ligera sospecha de que a mediados de cursado me lo he "encontrado" en la 33 JAIIO en el 2004; antes de que el proyecto cambiara de rumbo.
No recuerdo bien que TORO Kernel (ex TORO OS) sea parte de su proyecto final para el título. Si en cambio que fue de inspiración académica. Si en verdad Matías Vara está haciendo este proyecto por el título, ¡que alguien le haga recordar mi experiencia! ¡Que no se meta en chaleco de 11 balas!

Saludos,

Disculpa , no conozco tu experiencia, que te paso?

[[rretamar]]

Empezado por mamcx

Tener soporte para proyectos latinos por latinos es bien dificil, no hay el mismo "espiritu" y la falta de recursos golpea bastante.

Desvirtuando un poco (o no tanto): A que te refieres con "espíritu" (supongo que a la falta de interés en colaborar con proyectos libres en la comunidad hispanoparlante) ?

¿ Y a que "falta de recursos" te refieres ? Supongo que al recurso "tiempo", es así ?.

[mamcx]

En parte, esta entrevista con el creador de ruby:

http://fredwu.me/post/36493181321/an...oto#page-about

Also, in Japan many programmers still spend most of the time at work (to put food on the table), it’s very difficult for them to contribute to open source projects. Ten years ago nobody cares about open source in Japan, but nowadays people start to realise the importance of open source, and the number of open source projects is growing. I believe China will soon follow this pattern as well, I am looking forward to it.

Si la gente de japon tiene dificultades economicas, imaginate por aqui. La realidad es de recursos ($$$$): Programar quita tiempo, y administrar un proyecto open source mucho mas. La realidad es que open source por si solo es una actividad empobrecedora -ie: open source da plata de forma indirecta, y por lo tanto es un costo negativo- , no en vano los proyectos open source por lo general son respaldados por empresas o gobierno o del amor de alguien... que ya tiene resuelto lo de "poner alimento en la mesa".

Y lo segundo es de "espíritu". Es mi impresión, pero en latino América hay mucho "bla bla" sobre el open source, lo libre, y como eso no significa siempre gratis, pero aun se nota que somos mas usuarios (y aprovechadores) que contribuidores.

[mamcx]

Empezado por mamcx

Es mi impresión, pero en latino América

Me puse a pensar que tan real era esa impresion, asi que corri una consulta con BigQuery contra github, y estos son los resultados usando:

Código SQL [-]
SELECT COUNT(*) AS Participation,actor_attributes_location
FROM [githubarchive:github.timeline]
GROUP BY actor_attributes_location
ORDER BY 1 DESC
LIMIT 500

que se pueden ver en
https://docs.google.com/spreadsheet/...F9mcFIxcGZmSmc

Aunque existe una marcada presencia de países/ciudades del "1er mundo" tal como se desprende de este mucho mas completo análisis me sorprendió ver a brasil, España & argentina entre las 100 ubicaciones* mas populares. Asi que parece que la cosa a mejorado mucho desde mis primeras experiencias hace unos años

* GitHub no tiene datos precisos del todo, ya que las ubicaciones las pone la gente como quiera (ciudad, país, región) pero es el único repositorio que conozco al que se le puede consultar sus datos directamente...

[donald shimoda]

Empezado por mamcx

Aunque existe una marcada presencia de países/ciudades del "1er mundo" tal como se desprende de este mucho mas completo análisis me sorprendió ver a brasil, España & argentina entre las 100 ubicaciones* mas populares. Asi que parece que la cosa a mejorado mucho desde mis primeras experiencias hace unos años

* GitHub no tiene datos precisos del todo, ya que las ubicaciones las pone la gente como quiera (ciudad, país, región) pero es el único repositorio que conozco al que se le puede consultar sus datos directamente...

Muy bueno lo suyo compañero, se pasa!

Pero que pasa con lo del país paisa no los veo en ese resultado.

Saludos.

[mamcx]

Empezado por donald shimoda

Muy bueno lo suyo compañero, se pasa!

Pero que pasa con lo del país paisa no los veo en ese resultado.

Saludos.

Pues esta en la posicion 257 de la hoja de calculo...

[donald shimoda]

Empezado por mamcx

Pues esta en la posicion 257 de la hoja de calculo...

Ups, se me habia pasado, estaba buscando medellin en realidad...

[[Delphius]]

Empezado por donald shimoda

Disculpa , no conozco tu experiencia, que te paso?

Dejémoslo en que haberse currado toda la carrera en 5 años, sin vacaciones, y en esforzarse el doble por cuenta propia en ir estudiando lo que va a ver en el siguiente semestre, las prácticas profesionales y el poco y mal dormir junto a 5 tazas de café pasaron factura. Adérece con problemas familiares y de salud que derivaron en un prolongado tiempo, necesario, obligatorio (y si... también hay que decirlo, merecido), de descanso, para hacer el típico análisis de la vida personal, sentimental, y hasta en lo psicológico.
Elíjase como proyecto de grado y objetivos el sacar el mayor provecho a las tan variadas cátedras que le iluminaron la cabeza, que te robaron sus horas de sueño porque estabas enganchando y fascinado por sus contenidos. Mezcle con temas relativamente nuevos, o poco tratados en este pedazo del planeta, que te impulsa a buscar material fuera y en otras lenguas, algo que tenga también de desafiante. Y Una sobre-confianza inicial que derivó a una infra-valoración de los riesgos y un análisis restrictivo-operativo pobre.

Creo que con eso se entiende

Saludos,

[donald shimoda]

Empezado por Delphius

Creo que con eso se entiende

Saludos,

Me canse de solo leerlo! Coincido, hay que balancear todo en la vida.