401 meneos
5279 clics
Las universidades de EEUU al fin lo han reconocido: empezar a programar por Java es una mala idea
Java ha sido y es desde hace mucho tiempo uno de los pilares básicos de la programación. Un lenguaje óptimo para según qué tareas. Sin embargo, su reinado como punto de partida para el estudiantado parece estar llegando a su fin. "Hay que aprender la lógica de la programación. El lenguaje es lo de menos. Por eso es un error enseñar con Java porque los programadores no tienen idea de lo que están haciendo", decía hace un par de años para Economía Digital Ricardo Galli, profesor universitario y socio-fundador de Menéame.
|
comentarios cerrados
Yo pienso que es un error usar espacios, sin embargo no veo nada de malo en enseñar a hacer las cosas coherentemente desde el principio. Empezar haciendo todo manual, pero cosas simples, para más adelante ir automatizando dichas cosas simples y centrarse en cosas más complejas.
Pero intenta hacer esto:
a= 8
b= "c"
c = 8 + c
Te va a dar un error, porque tienes un tipo entero + un tipo string. Y te va a petar. Esto es porque es tipado fuerte pero dinámico. No necesito de clarar que tipo de variable voy a usar.
Además las plantillas impiden hacer un uso creativo del espacio, por ejemplo en mis proyectos, si tengo el ruler (la línea que marca hasta dónde terminar las líneas) a 80 carácteres, a veces pongo ciertos comentarios justo a partir de dichos 80 carácteres, así quedan justo a la derecha del ruler, es muy útil para anotar ciertos TODO: y que queden muy visibles.
Recuerdo que una vez leí un artículo sobre lo difícil que era hacer un formateador de código que dividiese las líneas largas de la mejor forma posible.
Por otro lado los formateadores de código no siempre están disponibles y es importante saber adaptarse y respetar las reglas de estilo del archivo en el que estás trabajando. Alguna vez me ha tocado editar código entregado en la universidad y al abrirlo estaba todo descuadrado porque habían mezclado espacios con tabuladores. Una persona no debería salir de la universidad así, y mucho menos estar dentro dando clase
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.
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.
c = 8 * "2"
Funciona y ejecuta sin problemas.
Eso no es un problema de tipos.
En C o cualquier otro lenguaje, esa operación equivalente haría lo mismo.
Mira, lee sobre esto:
en.wikipedia.org/wiki/Strong_and_weak_typing
Un ejemplo de tipo débil, serían las variables Variant de Visual Basic.
No te quito razón en la teoría.
Pero te explica como funciona todo. A partir de conocer ese puedes intuir q hacer por debajo otros como python o java...
Y si estas aprendiendo...
Tampoco digo conseguir ser hipereficientes en C, sino tener unos conceptos y capacidades basicas para interiorizar como funciona.
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.
E incluso con Pascal/FreePascal puedes llegar hasta la POO.
Depende del environment
Empezar con php estructurado, pasar a php orientado a objetos y luego ya si eso a Java. Pero nunca nunca empezar por Java.
Cuando yo me pase de backend a frontend empecé con uno de la pragmatic library y ese que comentas, y hace poco repasé "Eloquent JavaScript: A Modern Introduction to Programming", que no está mal tampoco (aunque es un poco llover sobre mojado, el de la serie the good parts ya te da una base decente).
Yo siempre he usado "indentar" pero no lo tengo muy claro...
- Dinámicos (que se establecen en "runtime") como los que citas, Javascript, Python, PHP, etc
- Estáticos: los tipos se establen y se comprueban antes de que el programa se ejecute (Java, C++)
O bien en:
- Tipos fuertes, una vez establecido el tipo de una variable no se puede cambiar, como en Python
- Tipos débiles, sí se pueden cambiar (JS, PHP)
Cada método debería tener un bloque try con multiples catch, donde tratas cada posible error como sea oportuno. Ahora bien, si no se trata el error en el bloque catch, que ocurre? La excepción se sigue elevando, método a metodo por la pila de llamadas hasta llegar a main y por ultimo, al sistema operativo. Fijate si has tenido oportunidades de capturar el error antes de llegar a main.
El siguiente código funciona en python y no da error en tiempo de ejecución
a=3
a="b"
b=2 * "c"
Indentación es un anglicismo (de la palabra inglesa indentation) de uso común en informática; no es un término reconocido por la Real Academia Española (consultado en la vigesimosegunda edición). La Real Academia recomienda utilizar «sangrado».
Y como tu dices identación...
a=3
a="b"
Es como si en C hiciera
int a
str a
Y la última declaración es la que tuviera valor.
Y sobre lo de b=2*"c" es válido porque le estas diciendo que escriba "c" 2 veces. Estás haciendo una operación válida sobre una cadena de texto.
En un tipado débil, no fallará una operación de tipo
a = 2 + "c"
En Python eso no funciona.
en.wikipedia.org/wiki/Python_(programming_language)
Typing discipline Duck, dynamic, strong
Estoy de acuerdo con #217: para aprender con C, mejor Pascal, que es más o menos equivalente, pero más simple para principiantes.
Cualquier aprendiz abandona el día uno si le metes en semejante berenjenal.
iOS lo resuelve mucho mejor... Tienes una librería compilada en C y Objective-c o swift te la leen al añadir los headers.
Cuando programas para una plataforma móvil el lenguaje es secundario. Lo relevante es manejarse con el entorno de desarrollo/ide... Conocer el sdk, los widgets, las interacciones etc. Ahí el primer lenguaje que aprendas da igual.
Con C aprendes a programar desde el cimiento. Y tardas mucho en hacer algo que mínimamente sirva para algo.
Con python o javascript muy rápidamente haces algo que sirva para algo pero te saltas toda la complejidad.
Personalmente no usaría un lenguaje para aprender a programar. Usaría dos: uno compilado, fuertemente tipado, y otro interpretado y dinámico.
auto u = std::make_unique<int>(1);
auto s = std::make_shared<int>(1);
std::vector<int> v {1,2,3,4,5};
Entre otras opciones.
Pero si puedes tener un objeto en la pila va a ser más eficiente que tenerlo en el "heap".
Actualmente es uno de los mas graves incovenientes de C# que no sabes qué rutinas pueden o no pueden lanzarte una excepción, pero aún así, es una mala práctica.
Pero si los bloques los implementan la mayoría de lenguajes modernos, como Java, C++ o Python. Que alternativa hay, a los try..except?
Es una técnica que se usa en programación funcional. Hay un vídeo de Andrei Alexandrescu que explica muy bien el concepto
En boost está también la librería Outcome.
try
proceso()
catch
throw( que_lo_gestione_otro)
A esto lo llamo estilo de programación de dar patadas Pero si obligas a la gente a escribir
if (proceso() == null)
...
En cierta manera le estás obligando a que sea él quien gestione el error o no. Pero como dirían en el circo, la función debe continuar.
No son comparables.
Es por eso por lo que los interfaces no se cambian, sino que se declaran como obsoletos.
El uso de excepciones es "discutible", aunque los trycatcheros se me tiraran encima, hay lenguajes
nuevos que las evitan por diseño, como google go
incluso con funciones en C puro y duro.
Pro lo demas, si te ciñes a los nuevos estándares, es una gozada
(sí, me gusta Boost)
Los errores cuestan más y más dinero arreglarlos cuanto más tiempo pasó desde el momento en que se cometieron/se introdujeron en el código. Que pienses que el coste de optimizar es comparable al coste de la RAM que te ahorras demuestra que no has tenido que pagar por errores en tiempo de desarrollo.
Cuando dices que no entiendes "para qué tipo de tarea puede ser ideal el Java" y lo comparas con COBOL y C (cuando ninguno de los dos son orientados a objetos, ni tienen GC, ni son multiplataforma y un largo etcétera) demuestras simplemente que no conoces Java lo suficientemente bien, y en tal caso, deberías replantearte la manera en que opinas sobre tecnología.
Primera parte, optimización prematura es un anti patrón. Segunda, ante rendimiento o legibilidad a no ser que sea un cuello de botella y sea mejor rediseñar el codigo, siempre es preferible la legibilidad. Y como última parte, el auto escalado y la paralelización están precisamente para este tipo de problemas.
Luego si quieres poder hablar se técnicas avanzadas de proceso de volumen de datos basadas en streaming, batching o envío de mensajes en plataformas como Kafka...
El problema de hacer algo funcional PURO a la hora de empezar a aprender a programar es que si quieres hacer algo medianamente serio y bien tienes que meterte en conceptos bastante complejos como monoides, mónadas (que son una puta pasada y tienen paralelos directos con otros conceptos matemáticos como la teoría de grupos), functores y demás pijerías.
Lo que sí es cierto es que casi cualquier introducción a la programación debería centrarse en enseñar los rudimentos del pensamiento lógico, arquitectura de ordenadores, algorítmica, estructuras de datos, etc, y dejar las características "especiales" de los lenguajes para mas adelante.
No conozco el Java bien , es cierto , solo hice mi proyecto fin de carrera con Java cuando todavia era una beta , y acabe aborreciendolo , quizas ahora con el Kotlin vuelva a probarlo en algun momento.
Java ha cambiado MUCHÍSIMO desde cuando dices haberlo usado. Si eso, se ha estado quedando detrás de C# que ha incorporado auténticas maravillas como Linq, que ya me gustaría haber tenido en Java.
No esperes a Kotlin para probar lo que puedes hacer con Java en 2017.