type language dynamically checkers dynamic-languages

dynamic-languages - checkers - dynamically typed language vs static typed language



¿Qué es lo que las personas encuentran tan atractivo acerca de los lenguajes dinámicos? (30)

Parece que todo el mundo se está subiendo al carro dinámico, no compilado últimamente. En su mayoría, solo trabajé en lenguajes compilados y estáticos (C, Java, .Net). La experiencia que tengo con los lenguajes dinámicos es similar a ASP (Vb Script), JavaScript y PHP. El uso de estas tecnologías ha dejado un mal sabor de boca cuando pienso en lenguajes dinámicos. Las cosas que normalmente hubieran sido captadas por el compilador, como los nombres de las variables mal escritas y la asignación de un valor del tipo incorrecto a una variable, no se producen hasta el tiempo de ejecución. Y aun así, es posible que no notes un error, ya que solo crea una nueva variable y asigna algún valor predeterminado. Tampoco he visto nunca que intellisense funcione bien en un lenguaje dinámico, ya que, bueno, las variables no tienen ningún tipo explícito.

Lo que quiero saber es, ¿qué personas encuentran tan atractivo acerca de los lenguajes dinámicos? ¿Cuáles son las principales ventajas en términos de cosas que los lenguajes dinámicos le permiten hacer que no se pueden hacer, o que son difíciles de hacer en los lenguajes compilados? Me parece que hace mucho tiempo decidimos que cosas como las páginas asp no compiladas arrojando excepciones de tiempo de ejecución era una mala idea. ¿Por qué hay un resurgimiento de este tipo de código? ¿Y por qué me parece al menos que Ruby on Rails realmente no se parece a nada que no pudieras haber hecho con ASP hace 10 años?

Aquí hay una QuickSort estáticamente tipada en dos líneas de Haskell (de haskell.org):

qsort [] = [] qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Y aquí hay una QuickSort de tipo dinámico en LISP (de swisspig.net):

(defun quicksort (lis) (if (null lis) nil (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x)))) (append (quicksort (remove-if-not fn r)) (list x) (quicksort (remove-if fn r))))))

Creo que estás predispuesto con tu elección de idioma aquí. Lisp es notoriamente paren-heavy. Un equivalente más cercano a Haskell sería Python.

if len(L) <= 1: return L return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Código de Python desde here

Ah, no vi este tema cuando publiqué una pregunta similar

Además de las buenas características que el resto de la gente menciona aquí sobre los lenguajes dinámicos, creo que todos olvidan una, lo más básico: la metaprogramación.

Programando el programa.

Es bastante difícil de hacer en lenguajes compilados, por lo general, tome por ejemplo .Net. Para que funcione, tienes que hacer todo tipo de mambo jumbo y normalmente termina con un código que corre alrededor de 100 veces más lento.

La mayoría de los lenguajes dinámicos tienen una forma de hacer metaprogramación y eso es algo que me mantiene ahí: la capacidad de crear cualquier tipo de código en la memoria y de integrarlo perfectamente en mi aplicación.

Por ejemplo, para crear una calculadora en Lua, todo lo que tengo que hacer es:

print( loadstring( "return " .. io.read() )() )

Ahora, intente hacer eso en .Net.

Al leer las respuestas de otras personas, parece que hay más o menos tres argumentos para los lenguajes dinámicos:

1) El código es menos detallado. No encuentro esto válido. Algunos lenguajes dinámicos son menos detallados que algunos estáticos. Pero F # está tipado estáticamente, pero el tipado estático no agrega mucho código, si lo hay. Sin embargo, está tipeado implícitamente, pero eso es algo diferente.

2) "Mi lenguaje dinámico favorito X tiene mi característica funcional favorita Y, por lo tanto, la dinámica es mejor". No confundas funcional y dinámico (no puedo entender por qué esto tiene que decirse).

3) En idiomas dinámicos, puede ver sus resultados de inmediato. Noticias: También puedes hacer eso con C # en Visual Studio (desde 2005). Simplemente configure un punto de interrupción, ejecute el programa en el depurador y modifique el programa mientras depura. Hago esto todo el tiempo y funciona perfectamente.

Yo mismo soy un firme defensor del tipado estático, por una razón principal: mantenibilidad. Tengo un sistema con un par de líneas de JavaScript de 10k, y cualquier refactorización que quiera hacer me tomará como medio día ya que el compilador (inexistente) no me dirá qué cambió el nombre de esa variable. Y ese es el código que yo mismo escribí, la OMI también está bien estructurada. No me gustaría la tarea de estar a cargo de un sistema dinámico equivalente que alguien más escribió.

Creo que seré derrotado masivamente por esto, pero correré el riesgo.

Creo que el "nuevo amor encontrado" para los lenguajes de tipado dinámico tiene menos que ver con si los lenguajes de tipo estático son mejores o peores, en el sentido absoluto, que con el aumento de la popularidad de ciertos lenguajes dinámicos. Ruby on Rails era obviamente un gran fenómeno que causaba el resurgimiento de los lenguajes dinámicos. Lo que hizo que los rieles fueran tan populares y creó tantos conversos del campo estático fue principalmente: muy escueto y código y configuración SECOS. Esto es especialmente cierto cuando se compara con frameworks web Java que requieren montañas de configuración XML. Muchos programadores de Java, también inteligentes, se convirtieron y algunos incluso rubís evangelizados y otros lenguajes dinámicos. Para mí, tres características distintas permiten que los lenguajes dinámicos como Ruby o Python sean más concisos:

  1. Sintaxis minimalista: la principal es que las anotaciones de tipo no son necesarias, pero también el diseñador del lenguaje diseñó el lenguaje desde el principio para que sea concisa.
  2. sintaxis de la función en línea (o la lambda): la capacidad de escribir funciones en línea y pasarlas como variables hace que muchos tipos de código sean más breves. En particular, esto es cierto para las operaciones de lista / matriz. Las raíces de estas ideas obviamente eran: LISP.
  3. Metaprogramación: la metaprogramación es una gran parte de lo que hace funcionar a los rieles. Dio lugar a una nueva forma de refactorizar el código que permitió que el código del cliente de su biblioteca fuera mucho más conciso. Esto también se originó de LISP.

Las tres características no son exclusivas de los lenguajes dinámicos, pero ciertamente no están presentes en los populares lenguajes estáticos de la actualidad: Java y C #. Se podría argumentar que C # tiene el n. ° 2 en delegados, pero yo diría que no se utiliza ampliamente en absoluto, como con las operaciones de lista.

En cuanto a los lenguajes estáticos más avanzados ... Haskell es un lenguaje maravilloso, tiene el número 1 y el número 2, y aunque no tiene el n. ° 3, su sistema de tipo es tan flexible que probablemente no encontrará la falta de meta para ser limitante Creo que puede hacer metaprogramación en OCaml en tiempo de compilación con una extensión de idioma. Scala es una adición muy reciente y es muy prometedor. F # para el campamento de .NET. Sin embargo, los usuarios de estos idiomas son minoría y, por lo tanto, no contribuyeron realmente a este cambio en el panorama de los lenguajes de programación. De hecho, creo mucho que la popularidad de Ruby afectó la popularidad de idiomas como Haskell, OCaml, Scala y F # de manera positiva, además de los otros lenguajes dinámicos.

Creo que este tipo de argumento es un poco estúpido: "Las cosas que normalmente hubieran sido captadas por el compilador, como los nombres de variables mal escritas y la asignación de un valor del tipo incorrecto a una variable, no ocurren hasta el tiempo de ejecución" sí, eso es correcto como Desarrollador de PHP No veo cosas como variables mal escritas hasta el tiempo de ejecución, PERO el tiempo de ejecución es el paso 2 para mí, en C ++ (que es el único lenguaje compilado que tengo) es el paso 3, después del enlace y la compilación.

Sin mencionar que demora unos segundos después de presionar Guardar cuando mi código está listo para ejecutarse, a diferencia de los lenguajes compilados, donde puede tomar literalmente horas. Lo siento si esto suena un poco enojado, pero estoy un poco cansado de que la gente me trate como un programador de segunda categoría porque no tengo que compilar mi código.

Creo que la razón es que las personas están acostumbradas a los lenguajes tipados estáticamente que tienen sistemas de tipo muy limitado e inexpresivo. Estos son lenguajes como Java, C ++, Pascal, etc. En lugar de ir en la dirección de sistemas de tipo más expresivos e inferencias de tipo mejor (como en Haskell, por ejemplo, e incluso SQL hasta cierto punto), a algunas personas les gusta simplemente mantener toda la información de "tipo" en su cabeza (y en sus pruebas) y eliminan totalmente la comprobación estática de tipos.

Lo que esto te compra al final no está claro. Hay muchas nociones erróneas acerca de la verificación de tipos, las que con mayor frecuencia encuentro son estas dos.

Falacia: los lenguajes dinámicos son menos detallados. La idea errónea es que la información de tipo es igual a la anotación de tipo. Esto es totalmente falso. Todos sabemos que la anotación de tipo es molesta. La máquina debería ser capaz de resolver esas cosas. Y, de hecho, lo hace en los compiladores modernos. Aquí hay una QuickSort estáticamente tipada en dos líneas de Haskell (de haskell.org ):

qsort [] = [] qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Y aquí hay una QuickSort de tipo dinámico en LISP (de swisspig.net ):

(defun quicksort (lis) (if (null lis) nil (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x)))) (append (quicksort (remove-if-not fn r)) (list x) (quicksort (remove-if fn r))))))

El ejemplo de Haskell falsifica la hipótesis estáticamente tipada, por lo tanto, prolija . El ejemplo de LISP falsifica la hipótesis verbosa, por lo tanto, está tipificada de forma estática . No hay implicación en ninguna dirección entre tipeo y verbosidad. Puedes olvidarlo de manera segura.

Falacia: los lenguajes de tipo estático deben compilarse, no interpretarse. Nuevamente, no es verdad. Muchos lenguajes estáticos tienen intérpretes. Está el intérprete de Scala, los intérpretes de GHCi y Hugs para Haskell, y por supuesto SQL ha sido tipificado e interpretado estáticamente por más tiempo del que he estado vivo.

Ya sabes, tal vez la multitud dinámica solo quiere la libertad para no tener que pensar con tanto cuidado sobre lo que están haciendo. El software puede no ser correcto o robusto, pero tal vez no sea necesario.

Personalmente, creo que aquellos que renunciarían a la seguridad tipo para comprar un poco de libertad temporal, no merecen ni libertad ni seguridad.

Mi aprecio por los lenguajes dinámicos está muy ligado a cuán funcionales son. Las listas de comprensión de Python, los cierres de Ruby y los objetos prototipados de JavaScript son facetas muy atractivas de esos idiomas. Todos también cuentan con funciones de primera clase, algo que no puedo ver viviendo sin otra vez.

No categorizaría PHP y VB (script) de la misma manera. Para mí, esos son en su mayoría idiomas imperativos con todos los inconvenientes de tipeo dinámico que sugieres.

Claro, no obtienes el mismo nivel de comprobaciones en tiempo de compilación (ya que no hay un tiempo de compilación), pero espero que las herramientas de comprobación de sintaxis estén evolucionando con el tiempo para abordar al menos parcialmente ese problema.

Mi razón principal para que me gusten los lenguajes dinámicos (mecanografiados, ya que ese parece ser el enfoque del hilo) es que los que he usado (en un entorno de trabajo) son muy superiores a los lenguajes no dinámicos que he usado. C, C ++, Java, etc ... son todos los lenguajes horribles para hacer el trabajo real. Me encantaría ver un lenguaje implícitamente tipado que es tan natural de programar como muchos de los que están tipeados dinámicamente.

Dicho esto, hay ciertos constructos que son simplemente increíbles en los lenguajes de tipado dinámico. Por ejemplo, en Tcl

lindex $mylist end-2

El hecho de que pase "end-2" para indicar el índice que desea es increíblemente conciso y obvio para el lector. Aún no he visto un lenguaje estáticamente tipado que logre tal.

No olvide que necesita escribir una cobertura de código 10x en pruebas unitarias para reemplazar lo que hace su compilador: D

He estado allí, hecho eso con lenguajes dinámicos, y no veo absolutamente ninguna ventaja.

Para mí, la ventaja de los lenguajes dinámicos es cuánto más legible se vuelve el código debido a menos código y técnicas funcionales como el bloqueo de Ruby y la comprensión de la lista de Python.

Pero luego echo de menos la comprobación del tiempo de compilación (el error ocurre) y el autocompletado IDE. En general, la menor cantidad de código y legibilidad me compensa.

Otra ventaja es la naturaleza generalmente interpretada / no compilada del lenguaje. Cambie un código y vea el resultado de inmediato. Es realmente un ahorro de tiempo durante el desarrollo.

Por último, me gusta el hecho de que puedes encender una consola y probar algo de lo que no estás seguro, como una clase o método que nunca has usado antes y ver cómo se comporta. Hay muchos usos para la consola y lo dejaré para que lo descubras.

Personalmente, creo que es solo que la mayoría de los lenguajes "dinámicos" que ha usado simplemente son malos ejemplos de idiomas en general.

Soy mucho más productivo en Python que en C o Java, y no solo porque tienes que hacer el baile edit-compile-link-run. Me estoy volviendo más productivo en Objective-C, pero eso es probablemente más debido al marco.

No hace falta decir que soy más productivo en cualquiera de estos idiomas que PHP. Demonios, preferiría codificar en Scheme o Prolog que en PHP. (Pero últimamente he estado haciendo más Prolog que cualquier otra cosa, ¡así que tómalo con un grano de sal!)

Soy un programador de .Net a tiempo completo totalmente atrincherado en medio del C # estáticamente tipado. Sin embargo, me encanta el JavaScript moderno.

En general, creo que los lenguajes dinámicos le permiten expresar su intención de forma más sucinta que los lenguajes estáticos, ya que dedica menos tiempo y espacio a definir cuáles son los componentes básicos de lo que está tratando de expresar cuando en muchos casos son evidentes.

Creo que también hay múltiples clases de idiomas dinámicos. No deseo volver a escribir páginas ASP clásicas en VBScript. Para ser útil, creo que un lenguaje dinámico necesita soportar algún tipo de colección, lista o construcción asociativa en su núcleo para que los objetos (o lo que pase para los objetos) se puedan expresar y le permitan construir construcciones más complejas. (Tal vez todos deberíamos codificar en LISP ... es una broma ...)

Creo que en .Net círculos, los lenguajes dinámicos tienen una mala reputación porque están asociados con VBScript y / o JavaScript. VBScript se acaba de recordar como una pesadilla por muchas de las razones que Kibbee afirmó: cualquiera recuerda utilizar el tipo en VBScript utilizando CLng para asegurarse de tener suficientes bits para un entero de 32 bits. Además, creo que JavaScript todavía se ve como el idioma del navegador para menús desplegables que se escribe de una manera diferente para todos los navegadores. En ese caso, el problema no es el lenguaje, sino los diversos modelos de objetos del navegador. Lo que es interesante es que cuanto más madura C #, más dinámico comienza a verse. Me encantan las expresiones de Lambda, los objetos anónimos y la inferencia de tipo. Se siente más como JavaScript todos los días.

Sus argumentos contra los lenguajes dinámicos son perfectamente válidos. Sin embargo, considere lo siguiente:

  1. Los lenguajes dinámicos no necesitan ser compilados : simplemente ejecútelos. Incluso puede volver a cargar los archivos en tiempo de ejecución sin reiniciar la aplicación en la mayoría de los casos.
  2. Los lenguajes dinámicos son generalmente menos detallados y más legibles : ¿alguna vez has mirado un algoritmo o programa determinado implementado en un lenguaje estático, y luego lo has comparado con el equivalente de Ruby o Python? En general, está viendo una reducción en las líneas de código por un factor de 3. Una gran cantidad de código de andamio no es necesario en los lenguajes dinámicos, y eso significa que el resultado final es más legible y más centrado en el problema real en cuestión.
  3. No se preocupe por los problemas de tipeo : el enfoque general al programar en lenguajes dinámicos es no preocuparse por el tipeo: la mayoría de las veces, el tipo correcto de argumento se transmitirá a sus métodos. Y de vez en cuando, alguien puede usar un tipo diferente de argumento que también funciona. Cuando las cosas van mal, su programa puede detenerse, pero esto rara vez ocurre si ha realizado algunas pruebas.

También me pareció un poco aterrador alejarme del mundo seguro de tipeo estático al principio, pero para mí las ventajas superan con creces las desventajas, y nunca he mirado hacia atrás.

Una de las ventajas señaladas para los lenguajes dinámicos es simplemente poder cambiar el código y seguir corriendo. No es necesario volver a compilar. En VS.Net 2008, al depurar, en realidad puede cambiar el código y continuar ejecutándolo, sin una recompilación. Con los avances en compiladores e IDEs, es posible que esta y otras ventajas de usar lenguajes dinámicos desaparezcan.

VBScript es una mierda, a menos que lo compares con otro sabor de VB. PHP está bien, siempre y cuando tengas en cuenta que es un lenguaje de plantillas demasiado grande. El Javascript moderno es genial. De Verdad. Toneladas de diversión. Solo aléjate de los scripts etiquetados como "DHTML".

Nunca utilicé un lenguaje que no permitiera errores de tiempo de ejecución. En mi humilde opinión, eso es en gran medida un secreto: los compiladores no detectan todos los errores tipográficos, ni validan el intento. La escritura explícita es excelente cuando se necesitan tipos explícitos, pero la mayoría de las veces, no. Busque aquí las preguntas sobre los generics o sobre si usar o no los tipos sin firmar es una buena opción para las variables de índice; la mayoría de las veces, esto se interpone en el camino, y le da a las personas perillas para mezclar cuando tienen tiempo en su manos.

Pero, realmente no he respondido tu pregunta. ¿Por qué son atractivos los lenguajes dinámicos? Porque después de un tiempo, escribir código se vuelve aburrido y solo desea implementar el algoritmo. Ya se sentó y resolvió todo en un bolígrafo, trazó un diagrama de posibles escenarios y demostró que podían solucionarlo, y lo único que queda por hacer es codificar las veinte líneas de implementación ... y doscientas líneas de repetición para compilar . Entonces te das cuenta de que el sistema de tipos con el que trabajas no refleja lo que realmente estás haciendo, sino la idea ultra abstracta de lo que podrías estar haciendo, y hace mucho tiempo que abandonaste la programación por una vida de ajustes sofisticados. obsesivo-compulsivo que avergonzaría incluso al detective de ficción Adrian Monk.

Ahí es cuando te ves enyesado y empiezas a mirar seriamente los lenguajes dinámicos.

Although I''m not a big fan of Ruby yet, I find dynamic languages to be really wonderful and powerful tools.

The idea that there is no type checking and variable declaration is not too big an issue really. Admittedly, you can''t catch these errors until run time, but for experienced developers this is not really an issue, and when you do make mistakes, they''re usually easily fixed.

It also forces novices to read what they''re writing more carefully. I know learning PHP taught me to be more attentive to what I was actually typing, which has improved my programming even in compiled languages.

Good IDEs will give enough intellisense for you to know whether a variable has been "declared" and they also try to do some type inference for you so that you can tell what a variable is.

The power of what can be done with dynamic languages is really what makes them so much fun to work with in my opinion. Sure, you could do the same things in a compiled language, but it would take more code. Languages like Python and PHP let you develop in less time and get a functional codebase faster most of the time.

And for the record, I''m a full-time .NET developer, and I love compiled languages. I only use dynamic languages in my free time to learn more about them and better myself as a developer..

Because I consider stupid having to declare the type of the box. The type stays with the entity, not with the container. Static typing had a sense when the type of the box had a direct consequence on how the bits in memory were interpreted.

If you take a look at the design patterns in the GoF, you will realize that a good part of them are there just to fight with the static nature of the language, and they have no reason whatsoever to exist in a dynamic language.

Also, I''m tired of having to write stuff like MyFancyObjectInterface f = new MyFancyObject(). DRY principle anyone ?

Because it''s fun fun fun. It''s fun to not worry about memory allocation, for one. It''s fun not waiting for compilation. etc etc etc

FWIW, Compiling on most applications shouldn''t take hours. I have worked with applications that are between 200-500k lines that take minutes to compile. Certainly not hours.

I prefer compiled languages myself. I feel as though the debugging tools (in my experience, which might not be true for everything) are better and the IDE tools are better.

I like being able to attach my Visual Studio to a running process. Can other IDEs do that? Maybe, but I don''t know about them. I have been doing some PHP development work lately and to be honest it isn''t all that bad. However, I much prefer C# and the VS IDE. I feel like I work faster and debug problems faster.

So maybe it is more a toolset thing for me than the dynamic/static language issue?

One last comment... if you are developing with a local server saving is faster than compiling, but often times I don''t have access to everything on my local machine. Databases and fileshares live elsewhere. It is easier to FTP to the web server and then run my PHP code only to find the error and have to fix and re-ftp.

I don''t have much experience with dynamic languages in general, but the one dynamic language I do know, JavaScript(aka ECMAScript), I absolutely love.

Well, wait, what''s the discussion here? Dynamic compilation? Or dynamic typing? JavaScript covers both bases so I guess I''ll talk about both:

Dynamic compilation :

To begin, dynamic languages are compiled, the compilation is simply put off until later. And Java and .NET really are compiled twice. Once to their respective intermediate languages, and again, dynamically, to machine code.

But when compilation is put off you can see results faster. That''s one advantage. I do enjoy simply saving the file and seeing my program in action fairly quick.

Another advantage is that you can write and compile code at runtime . Whether this is possible in statically compiled code, I don''t know. I imagine it must be, since whatever compiles JavaScript is ultimately machine code and statically compiled. But in a dynamic language this is a trivial thing to do. Code can write and run itself. (And I''m pretty sure .NET can do this, but the CIL that .NET compiles to is dynamically compiled on the fly anyways, and it''s not so trivial in C#)

Dynamic typing :

I think dynamic typing is more expressive than static typing. Note that I''m using the term expressive informally to say that dynamic typing can say more with less. Here''s some JavaScript code:

var Person = {};

Do you know what Person is now? It''s a generic dictionary. I can do this:

Person["First_Name"] = "John"; Person["Last_Name"] = "Smith";

But it''s also an object. I could refer to any of those "keys" like this:

Person.First_Name

And add any methods I deem necessary:

Person.changeFirstName = function(newName) { this.First_Name = newName; };

Sure, there might be problems if newName isn''t a string. It won''t be caught right away, if ever, but you can check yourself. It''s a matter of trading expressive power and flexibility for safety. I don''t mind adding code to check types, etc, myself, and I''ve yet to run into a type bug that gave me much grief (and I know that isn''t saying much. It could be a matter of time :) ). I very much enjoy, however, that ability to adapt on the fly.

I have love for both static and dynamic languages. Every project that I''ve been involved in since about 2002 has been a C/C++ application with an embedded Python interpret. This gives me the best of both worlds:

  1. The components and frameworks that make up the application are, for a given release of an application, immutable. They must also be very stable, and hence, well tested. A Statically typed language is the right choice for building these parts.
  2. The wiring up of components, loading of component DLLs, artwork, most of the GUI, etc... can vary greatly (say, to customise the application for a client) with no need to change any framework or components code. A dynamic language is perfect for this.

I find that the mix of a statically typed language to build the system and a dynamically type language to configure it gives me flexibility, stability and productivity.

To answer the question of "What''s with the love of dynamic languages?" For me it''s the ability to completely re-wire a system at runtime in any way imaginable. I see the scripting language as "running the show", therefore the executing application may do anything you desire.

I think both styles have their strengths. This either/or thinking is kind of crippling to our community in my opinion. I''ve worked in architectures that were statically-typed from top to bottom and it was fine. My favorite architecture is for dynamically-typed at the UI level and statically-typed at the functional level. This also encourages a language barrier that enforces the separation of UI and function.

To be a cynic, it may be simply that dynamic languages allow the developer to be lazier and to get things done knowing less about the fundamentals of computing. Whether this is a good or bad thing is up to the reader :)

I think that we need the different types of languages depending on what we are trying to achieve, or solve with them. If we want an application that creates, retrieves, updates and deletes records from the database over the internet, we are better off doing it with one line of ROR code (using the scaffold) than writing it from scratch in a statically typed language. Using dynamic languages frees up the minds from wondering about

  • which variable has which type
  • how to grow a string dynamically as needs be
  • how to write code so that if i change type of one variable, i dont have to rewrite all the function that interact with it

to problems that are closer to business needs like

  • data is saving/updating etc in the database, how do i use it to drive traffic to my site

Anyway, one advantage of loosely typed languages is that we dont really care what type it is, if it behaves like what it is supposed to. That is the reason we have duck-typing in dynamically typed languages. it is a great feature and i can use the same variable names to store different types of data as the need arises. also, statically typed languages force you to think like a machine (how does the compiler interact with your code, etc etc) whereas dynamically typed languages, especially ruby/ror, force the machine to think like a human.

These are some of the arguments i use to justify my job and experience in dynamic languages!

Nice blog post on the same topic: Python Makes Me Nervous

Method signatures are virtually useless in Python. In Java, static typing makes the method signature into a recipe: it''s all the shit you need to make this method work. Not so in Python. Here, a method signature will only tell you one thing: how many arguments you need to make it work. Sometimes, it won''t even do that, if you start fucking around with **kwargs.

Productivity in a certain context. But that is just one environment I know, compared to some others I know or have seen used.

Smalltalk on Squeak/Pharo with Seaside is a much more effective and efficient web platform than ASP.Net(/MVC), RoR or Wicket, for complex applications. Until you need to interface with something that has libraries in one of those but not smalltalk.

Misspelled variable names are red in the IDE, IntelliSense works but is not as specific. Run-time errors on webpages are not an issue but a feature, one click to bring up the debugger, one click to my IDE, fix the bug in the debugger, save, continue. For simple bugs, the round-trip time for this cycle is less than 20 seconds.

Put yourself in the place of a brand new programmer selecting a language to start out with, who doesn''t care about dynamic versus staic versus lambdas versus this versus that etc.; which language would YOU choose?

DO#

using System; class MyProgram { public static void Main(string[] args) { foreach (string s in args) { Console.WriteLine(s); } } }

Lua:

function printStuff(args) for key,value in pairs(args) do print value .. " " end end strings = { "hello", "world", "from lua" } printStuff(strings)

The argument is more complex than this (read steve.yegge.googlepages.com/is-weak-typing-strong-enough for an interesting overview).

Dynamic languages don''t necessarily lack error checking either - C#''s type inference is possibly one example. In the same way, C and C++ have terrible compile checks and they are statically typed.

The main advantages of dynamic languages are a) capability (which doesn''t necessarily have to be used all the time) and b) Boyd''s Law of Iteration .

The latter reason is massive.

This all comes down to partially what''s appropriate for the particular goals and what''s a common personal preference. (EG Is this going to be a huge code base maintained by more people than can conduct a reasonable meeting together? You want type checking.)

The personal part is about trading off some checks and other steps for development and testing speed (while likely giving up some cpu performance). There''s some people for which this is liberating and a performance boost, and there''s some for which this is quite the opposite, and yes it does sort of depend on the particular flavor of your language too. I mean no one here is saying Java rocks for speedy, terse development, or that PHP is a solid language where you''ll rarely make a hard to spot typo.

Weakly typed languages allow flexibility in how you manage your data.

I used VHDL last spring for several classes, and I like their method of representing bits/bytes, and how the compiler catches errors if you try to assign a 6-bit bus to a 9-bit bus. I tried to recreate it in C++, and I''m having a fair struggle to neatly get the typing to work smoothly with existing types. Steve Yegge does a very nice job of describing the issues involved with strong type systems, I think.

Regarding verbosity: I find Java and C# to be quite verbose in the large(let''s not cherry-pick small algorithms to "prove" a point). And, yes, I''ve written in both. C++ struggles in the same area as well; VHDL succumbs here.

Parsimony appears to be a virtue of the dynamic languages in general(I present Perl and F# as examples).