#205 en el contexto del que hablamos es de si se tiene o no que declarar el tipo de variable.
No te quito razón en la teoría.
#210 Entonces estamos de acuerdo en el concepto, pero no en la terminología
Ciertamente, en Python no necesitas declarar la variable, pero eso no no significa que no haya tipos de variables. Y que, si intentas hacer operaciones con el tipo equivocado de variables te vaya a petar.
E incluso en Python podrías declarar una variable. Por ejemplo:
from typing import List
Vector = List[float]
def scale(scalar: float, vector: Vector) -> Vector:
return [scalar * num for num in vector]
Aunque eso no es lo común.
#185 Si yo por ejemplo defino una variable como
a= 8
Y luego intento guardar en esa variable
a= "b"
Tú no has programado en Python.
Confundis tipado dinámico/estático con débil/fuerte.
Cuando se habla de tipado no nos hacemos tanto la picha un lío. O está tipado o no, sin entrar en profundidad.
¿Se espeficifica el tipo de variable?
NO Por tanto se considera no tipado.
#200 Yo he programado en Python. Y programo en Python.
Mentira. Hay tipados dinámico/estático y débil/fuerte.
Que no declare la variable, no significa que no esté tipado. Simplemente no la tengo que declarar antes.
Sí, quise sobresimplificar el ejemplo de los tipados, y no pensé en que sobreescribía la definición.
Intenta en Python:
a= 1
b="a"
c= a + b
A ver que te sale. En JavaScript eso te funcionaría, en Python no, te da un error de tipo incompatible.
#210 Entonces estamos de acuerdo en el concepto, pero no en la terminología
Ciertamente, en Python no necesitas declarar la variable, pero eso no no significa que no haya tipos de variables. Y que, si intentas hacer operaciones con el tipo equivocado de variables te vaya a petar.
E incluso en Python podrías declarar una variable. Por ejemplo:
from typing import List
Vector = List[float]
def scale(scalar: float, vector: Vector) -> Vector:
return [scalar * num for num in vector]
Aunque eso no es lo común.
#200 si no especificas el tipo de variable entonces es tipado dinámico (frente a estático).
Tipado fuerte o débil se refiere a sí puedes trabajar con variables de distinto tipo o no. Por ejemplo en JavaScript puedes hacer 8+"3", por lo que es tipado débil. En Python no puedes, por lo que es tipado fuerte.
#200 Se especifica de forma dinámica, en ejecución.
#133 estamos hablando de introducir al personal en la programación, no usar Python para todo.
#118 Matlab en realidad lo utilizan ingenieros de * para facilitar muchos cálculos. Da igual que programes más bonito o no.
#134 Vale lo utilizan ingenieros en general, pero es mala forma de iniciarse ademas de requerir una licencia. Hay muchas empresas de ingenieria que no gastan ni un centimo en licencias de Matlab por distintos motivos, y ademas es un crimen habiendo alternativas como Python y Julia. Octave ni lo menciono porque tiene una velocidad ridiculamente lenta.
#125 muchas veces pagan su frustación con nosotros.
#126 Sí, tiene tipado fuerte, pero dinámico. Ya he puesto varios ejemplos.
#18 Python no tiene punteros, no es verbose, los conceptos de estructuras son más rápidos y sencillos de implementar, se puede crear aplicaciones interesantes con más facilidad y menos líneas de código,etc.
En definitiva, la curva de aprendizaje es más corta y la barrera de acceso al mundo de la programación es más fácil de saltar.
#56 En general estoy de acuerdo, pero también pienso que python tiene mucha magia entre medias, y eso también puede ser contraproducente. No te olvides que al final lo que se intenta es educar a un profesional, si es por escribir líneas de código y hacer cosas, pues igual no necesitas ir a una universidad para aprender python...
#56 el problema es que en el mundo laboral, al final tendrás que aprender Java. Porque no aprenderlo desde el principio?
#16 hace 40 años existía Java? Jaja
#20 claro para que optimizar... más madera!
#44 obviamente tampoco he querido decir eso. Pero que Java es perfectamente usable para la mayoría de entornos, pese a no ser el lenguaje mas optimizado, es un hecho (por eso se usa en todas partes) . Eso no quiere decir que tengamos que programar sin tener en cuenta el rendimiento, eso nunca, claro.
#4 como en este mundo sólo existen las aplicaciones de escritorio...
#62 Y así a lo tonto llega un día en que no puedes meter más RAM y en vez de 50 horas son 2300
#62 No se trata de optimizar. Se trata de saber o no programar.
El problema con enseñar a la gente usando Java no es que luego no saben optimizar. El problema es que no entienden como funciona el programa y el SO a bajo y medio nivel. No saben cual es el resultado físico de lo que programan.
En definitiva, no saben programar.
Si sabes programar de verdad la optimización que hay que hacer es nula o marginal.
Lo veo continuamente en el trabajo. Hay cosas que no hay que optimizar, simplemente jamás se les debería haber pasado por la cabeza programarlas de esa manera.
Por ejemplo que una aplicación pida gigas de datos a un motor de base de datos y luego filtre los datos.
Eso jamás habría que haberlo programado así por que nada es más eficiente que el propio motor de la DB filtrando datos.
Etc...
#161 No si ya, si lo vivo a diario, la gente programa a cañonazos y luego "egke esto tarda mucho", "egke me tuesta el SQL Server cuando lo lanza" etc etc. Yo aprendí a programar en papel, pascal y C, al menos en mis tiempos en mi facultad era así, pensando en la complejidad de los algoritmos etc etc. Pero la triste realidad es que la gente se molesta muy poco, en este y en otros tantos trabajos...
Decir que programar en lenguaje COBOL es más divertido, más fácil, más productivo, más bonito, más legible, etc... que Java o C++, es ir muy de hipster desesperado. También es de no tener ni puñetera idea.
Mis más sincera admiración por la dedicación de estos científicos
Pues como la I.A. aprenda a hacer huelgas...
Pues una manera de protestar es retirar el dinerito que uno tenga en La Caixa
#114 ya veo que para ti programar es sólo picar código. Pues a mi no me enseñaron eso en la uni. Diseñar forma parte del desarrollo y en todas las partes me identifico con mis competencias. Trabajar con unity puede formar parte de mi tarea como desarrollador y a mis colegas que trabajan con ella les llamo programadores (y son ingenieros). Otra cosa es diseñar escenarios con blender y demás tareas artísticas superimportantes.
Puede que no lo digas por despreciar, pero aclarar que programar no es sólo picar código (y me repito).
En cuanto al concepto de apaño, se debe mayoritariamente a una planificación incompleta o defectuosa, y aun siendo muy buena, las ocurrencias de los que pagan hacen que se tengan que hacer piruetas en el código.
Lo que suele pasar es que se confunden trucos (técnicas) con apaños (mal planificación).
#115 Yo no solo programo, hago de todo un poco, una de las cosas que se me da mejor es crear assets o pintado/crear texturas y si busco trabajo de eso no me ofrezco como programador.
Si quiero dedicarme al diseño de niveles me ofrezco como diseñador de niveles o escenarios no como programador.
Y bien orgullo estoy de mi trabajo y no me ofende como se ve algunos por aquí que no se me catalogue erroneamente en ese caso como programador.
Le puedes dar todas las vueltas que quieres, pero el que diseñar niveles no es un programador ni falta que hace.
Claro que puedes ser las tres cosas o cuatro, pero meterte en unity o cualquier otro a crear un nivel no, no te convierte en programador.
#52 y si no programas en ensablador eres una nenazas 😑 Lo que hay que oir!
#113 No tiene que ver una cosa con otra, como dije en otro comentario el que hace escenarios no es programador es diseñador de escenarios, y si quieres decir que haces juegos pues dices "Diseño juegos o niveles", como el que hace las animaciones no es programador es animador, cada uno tiene su rol en la cadena y ese rol tiene un nombre. Y hacer una cosa no te convierte en otra.
Os puede parecer un insulto pero no iban por ahí los tiros, no desmerezco la labor de nadie en la cadena, simplemente es lo que es.
#114 ya veo que para ti programar es sólo picar código. Pues a mi no me enseñaron eso en la uni. Diseñar forma parte del desarrollo y en todas las partes me identifico con mis competencias. Trabajar con unity puede formar parte de mi tarea como desarrollador y a mis colegas que trabajan con ella les llamo programadores (y son ingenieros). Otra cosa es diseñar escenarios con blender y demás tareas artísticas superimportantes.
Puede que no lo digas por despreciar, pero aclarar que programar no es sólo picar código (y me repito).
En cuanto al concepto de apaño, se debe mayoritariamente a una planificación incompleta o defectuosa, y aun siendo muy buena, las ocurrencias de los que pagan hacen que se tengan que hacer piruetas en el código.
Lo que suele pasar es que se confunden trucos (técnicas) con apaños (mal planificación).
#115 Yo no solo programo, hago de todo un poco, una de las cosas que se me da mejor es crear assets o pintado/crear texturas y si busco trabajo de eso no me ofrezco como programador.
Si quiero dedicarme al diseño de niveles me ofrezco como diseñador de niveles o escenarios no como programador.
Y bien orgullo estoy de mi trabajo y no me ofende como se ve algunos por aquí que no se me catalogue erroneamente en ese caso como programador.
Le puedes dar todas las vueltas que quieres, pero el que diseñar niveles no es un programador ni falta que hace.
Claro que puedes ser las tres cosas o cuatro, pero meterte en unity o cualquier otro a crear un nivel no, no te convierte en programador.
#213