Mensajes

Thinking in Java (Pensando en Java) tiene una versión en español y capaz que sea tan bueno como su contraparte de C++.

Lo que pasa es algo así:

Código (c) [Seleccionar] Expandir


unsigned int abs(int nro){
   return (nro < 0)?-nro:nro;
}

y tu código es algo así:

Código (c) [Seleccionar] Expandir


unsigned int abs(int nro){
   if(nro < 0){
       return nro * -1;
   }else{
       return nro;
   }
}

en el cual ambos están bien, pero son un poco diferentes uno de otro.

jajajajaja, preguntale al profesor si está bien, o si querés saber si están bien hechas por lo menos posteá el código, adivinos no hay (que yo sepa)

Una pregunta Erik#, si no tienes nivel para hacer un juego, si lo tienes para hacer un LP 

Perdón, permiso... son dos cosas totalmente diferente, es más hacer un juego puede considerarse un poco más complicado porque a veces requiere  hacer un lenguaje de programación para hacer la lógica (bah, en realidad sería más largo).

Peleas aparte, has de tomar muchas cosas en cuenta, y como dijo Radical, la maquina de Turin, es indispensable para tu objetivo por lo que he leido, si crees que te voy a insultar o criticar, lo siento pero no quiero bajarme a tu nivel, solo me queda decirte, buena suerte con tu proyecto, porque creo que la necesitaras

Salu2!

Ja!, desde cuando?, si vas a hacer un lenguaje pensando en la máquina de tuning debes conocerla, si vas a hacer un lenguaje en base a la máquina Lisp debes conocer la máquina Lisp, si vas a crear tu propia máquina...

Ahora Erik#, ten en cuenta que no es tarea sencilla, ¿tienes idea de BNF(Backus-Naur form)?, ¿cuáles serían los tokens del lenguaje?, ¿cómo será la sintaxis?, ¿qué estructuras de control llevará?, ¿será fuertemente tipado, tipado dinámico?. En fin, creo que equivocaste el camino, un LP tiene un par de pasos extensos antes de su programación, y definir su gramática (que en cima no debe ser ambigua).

    No entiendo tu pregunta. En si, si el número es en coma flotante no es primo, el factorial se complica y bastante su cálculo y la tabla de multiplicar es sencilla.

    Igual, no das prescición en qué estás fallando o cómo te podemos ayudar.

[pros:]

@ANIBAL: Puse que mayormente es opensource porque hay programas que te dan la oportunidad de crear archivos .exe de tus .py, aunque no se si crear archivos temporales con el código en python.

Entonces le estás errando, todo los lenguajes de script según tu concepción serían openSource. Igual, en python puedes no entregar el código y sólo entregar los .pyc (que son algo así como código python compilado) aunque sigues necesitando el intérprete (el bittorrent de windows usa ésta técnica), en fin a lo que voy es que no puedes ponerlo como contra ya que es una falencia de los lenguajes de scripting o sea que todos los lenguajes de éste tipo tendrán ese problema y si todos tienen ese problema no es una contra de un lenguaje particular.

Ahora voy a por ruby (ja!, siempre quise decir algo así):
pros:
Es íntegramente orientado a objetos (incluso las clases son objetos)
Second chance, si un objeto no sabe cómo responder a un método se le da una segunda oportunidad (creo que se llama al método method_mising) para que vea si puede resolverlo (hasta el momento conozco 3 lenguajes que implementan ésto, SmallTalk, Ruby y Objective C (y éste es compilado ))
Las clases están abiertas, ésto es que puedo agregar o reescribir métodos de cualquier clase en cualquier parte del programa (incluso de las clases nativas del lenguajes)
Bloques (clousures)
Mixin, poder agregar a una clase métodos de un módulo.
Existe documentación en inglés (ésto es muy positivo ya que el lenguaje es japonés, y hace poco que se tradujo su documentación a inglés).
Poder ejecutar comandos del sistema operativo con sólo `` (ejemplo `ls -l`).
Contras
Mucha convensión de nombres, para que sea constante debe empezar con mayúscula, las variables de clases deben empezar con @@, etc.
Abuso de end's, cada bloque termina con ends, puede llegar a ser desventajoso.
Muchas formas de hacer lo mismo (eso genera que el código quede confuso, es más programadores perl famosos por querer hacer todo en una sóla línea hagan cosas raras que sólo ellos entienden).
Es lento (incluso su versión de java jruby es más rápido), aunque en la versión 1.9 ésto parece solucionado.

[$arreglo[29]]

Es una desventaja poseer variables con distintos tipos de datos definidos??? Que acaso no aplica este mismito caso en lenguajes mas profundos tipo C/C++? Yo lo veo bastante ventajoso conocer cuando una variable es de algun tipo... porque por ejemplo en el caso de PHP, no se realmente cuando cierta variable se refiere a un arreglo, o a una referencia asociativa o a una variable que guarda caracteres o numeros la verdad.... Solo me doy cuenta si me dirigo en ocasiones donde se declaro la variable y esto sinceramente no es ninguna ventaja, al menos para mi, prefiero conocer que tipo de dato es una variable para saber que estoy manejando sin mucho rollo....

Intentaré explicarme mejor, es cierto el tener diferente prefijo sobre el nombre de la variable para saber de que tipo es es muy ventajoso, ahora la desventaja viene en que para (por ejemplo) acceder a un elemento de un arreglo se utiliza un $arreglo[29], ahora, no recuerdo bien, pero si es arreglos de arreglos, ¿debería ser @arreglo[10]?, ves la diferencia y a lo que yo apunto, eso si es bastante engorroso y podría (y es mas creo que en la versión 6 es donde se empieza a aplicar) siempre se acceda con @arreglo[indice]. Yo recuerdo que cuando intenté ver el por qué de que lo llaman un lenguaje difícil a perl lo primero que vi fue la distinción de nombrar a las variables (llámese @, $ y %) y dije "pero eso es muy bueno", hasta que llegué a la parte de cómo se accede a un elemento contenido en un arreglo o un dicionario, y ahí es donde se me hizo el metete. Insisto tiene su lógica y cuando se entiende la lógica es muy coherente y puede uno acostumbrarse y convivir con ello.

Perl si es orientado a objetos, tengo un buen libro sobre Perl, en donde se trata ese tema.

Object Oriented Perl, de Damian Conway

Saludos.

Jajajajaja, C es altamente procedural sin embargo se puede hacer orientación a objetos (GLib es un ejemplo), Lisp es funcional y tiene objetos, se puede hacer algo parecido a la orientación a objetos con perl, pero es un "hack" (utilizar diccionarios creo), el lenguaje no está preparado para ello (bueno, en la 5 lo prepararon un poco mejor, pero igual sigue sin ser orientado a objetos), la versión 6 (y ésta es la que descompagina todo) es la primera que implementa Orientación a Objetos en perl

[no]

@The Queen Of Ice, creo que tanto ruby, tcl y batch están tachados porque no tienen ningún pros y contra (no porque Erik# no los considere lenguajes).

Agrego otra cosa (que yo en opinión personal) creo que es una gran desventaja de perl, en perl cada variable tiene tipo y ese tipo se define con el nombre de la variable (@, $ y creo que %, aunque no recuerdo bien $ variable escalar, @ creo que lista/arreglo y % me parece que es diccionario), igual, algo con que se llega a confundir hasta que se le agarre la mano es lidiar con esos prefijos de variables y que para acceder a una posición concreta del arreglo se tiene que usar $ (ejemplo $arreglo[10]), si bien tiene su lógica, confunde al principio, si bien en la versión 6 si no me equivoco cambian eso y ahora si es un arreglo se hace @arreglo[10]. Otra cosa, perl no es orientado a objetos, si bien se puede llegar a lograr algo parecido, es puro hack y el lenguaje no fue pensado así (ahora la versión 6 es la primera que incorpora objetos). Pro de perl se puede acceder a los comandos del sistema operativo con ``, muy bueno, otra cosa es que permite crear arreglos de string de una forma fácil (no recuerdo bien como, lo vi muy por arriba a éste lenguaje pero se que se puede).

Su diseño grafico es de bastante mala calidad.

Si la serpiente es bastante fea... ¿qué quieres decir conque su diseño gráfico es bastante mala calidad?, no es un lenguaje de diseño gráfico (aunque se puede integrar con gimp).

No puedes crear juegos con graficos excelentes ni notables.

Claaaaro, y pygame es una librería que no sirve para nada...

Necesitas un programa o mejor dicho un interprete para poder hacer funcionar los códigos.

Eso es cierto puede verse como contra.

Para los que no apoyan el openSource, mayormente este lenguaje es openSouce .

Que yo sepa, el lenguaje es completamente openSource, es más me parece que es de código libre, igual existen librerías que pueden ser cerradas.

Documentación sobre librerias interesantes como TK, GTK, PyGAME, PyOGRE no hay mucha en castellano.

Tk, ni siquiera en inglés, es bastante dificil encontrar ese tipo de información

Para poder hacer funcionar librerias no estandar hay que instalarlas para poder ejecutar los scripts.

Por lo general en cualquier lenguaje pasa eso... a ver, no me equivoco, en todos los lenguajes pasa eso, por algo no son estándar.

Te puedes liar si eres muy novato con las sangrias.

Si, puede ser.

Como contras, yo agregaría, se puede llegar a confundir los bloques si se mezclan tabs y espacios (igual está sumamente desaconsejado hacer eso).

Cómo que nada de álgebra si el determinante de una matriz es de álgebra. Esto es tan sencillo, es sólo cuestión de encontrar la definición, ver un método de cómo calcularla y transformar ese método en el algoritmo en el lenguaje que te gusta.