Al menos para mi gusto ser fuertemente tipificado es una gran ventaja con respecto a no serlo.
Y tu gusto a qué está limitado? Me demuestras que de construcción de lenguajes sabes lo que tus comentarios me han demostrado.
Funciones de Alto Orden: Una de las principales características de los lenguajes funcionales es la facilidad que presenta para tratar funciones como objetos, lo que permite aceptarlas como parámetros de otras funciones, retornarlas como resultado y permitir que otras estructuras de datos las contengan dentro de sus componentes.
Desde luego que C# no tiene los mismo tal cual , pero tampoco lo necesita:
delegados (delegates). si entendi bien a que se refieren con Funciones de alto orden:
El delegado que apunta a la funcion, puede ser enviado como parametro a cualquier otro metodo, los metodos tambien pueden devolver delegados.
Sé qué es un Delegate, pero tu no sabes de lo que me estás contestando. Los Delegates pueden ayudarte a construir Dispatch Tables ( corre a wikipedia a leer que es eso ), pero jamás podrán ser funciones de alto orden, simplemente porque las funciones en C# NO son objetos.
respecto a las variables lexicas... si sabes algo de POO y de .net te daras cuenta que no necesitan dicha habilidad, para eso existe POO y en varios lenguajes hay modificadores de acceso, en el caso de C# puedes usar:
public
private
internal
static
protected
y dentro de las metodos miembro el contexto de una variable se puede limitar a cualquier bloque de codigo dentro del mismo bien sea para todo el bloque, para solo un bloque condicional etc. Tambien se peuden crear atributos static para proponer su uso de manera global en el ensamblado o los ensamblados... usando la palabra reservada
using
Y todo eso que dijiste QUE TIENE QUE VER con una variable léxica? me estás hablando de accesibilidad... Pero ok, no te preocupes, tu contador de palabras sigue incrementando, pero el significado que le das a las respuestas disminuye.
Por cierto...
using define "Namespaces", eso explica tu comentario de "crear atributos static para proponer su uso..."?, no necesitas decir TANTA palabrería si realmente conocieras lo que estás diciendo.
no puedes tener funciones que pre-fabriquen otras funciones ( por elementos citados atrás ).
Si se peude, aunque en tu vasto conocimiento no lo sepas. Por supuesto que se pueden generar ensamblados dinamicos en memoria usando .NET.
FYI
-Refleccion de tipos
-Module Builder
Y nuevamente eso qué? Java también cuenta con Reflection y características básicas de introspección de código, pero eso qué tiene que ver con una función que fabrique otra funcion? nuevamente C# y Java no son lenguajes que tomen características funcionales, los bloques de código NO son objetos. Tu contador sigue incrementando.
No se según tu que gran ventaja tiene usar algo como POD contra usar un standart global como XML.
Sabes qué tan "eficiente" es tu "standart global"? ( por cierto, es 'standard' ).
XML como metalenguaje y herramienta es excelente, analizarlo es caro, POD se sugirió desde antes que XML representara lo que es ahora, POD tiene muchísimo tiempo, y se hizo herramienta factible para documentar en Perl. No estoy comparando uno con otro, simplemente en Perl ( así como en otros lenguajes ) no necesitaron de XML, y obviamente puedes transformar POD a otros formatos ( como HTML ).
Así que POD es pequeño, es portable, es sencillo de generar, y por lo tanto sencillo de analizar. Esa fué la ventaja que se le encontró.
jajajaja!!! ah no? que profundo conocimiento de C# y de .NET tienes verdad... sabes que es el .NET fram,ework? parece que no, pero tlo que has mencionado esta muy ampliamente soportado, no se de donde sacas que .net no... eso es ridiculo y es una afirmacion ilogica.
Creo que no entendiste a lo que me refiero con frameworks externos, creados por la comunidad y altamente mantenidos. Definitivamente el tiempo que tiene viviendo cada lenguaje marca esa diferencia.
ahh no?
entonces que son?
Estas mal, no hablare por java. Pero c# es un leguaje.
Deberías aprender a leer detenidamente la documentación, nuevamente C# NO es un lenguaje, es una
especificación.creada por Microsoft a mediados de los 90's. Define un comportamiento de lenguaje, sus APIs y en la especificación encontrarás lo que NO está definido.
; de qué? de un lenguaje, de una máquina virtual
El lenguaje de la 'maquina virtual' de .NET si es que se le puede llamar maquina virtual porque no lo es realmente , al meno no desde el mismo punto de vista de java, es el MSCIL, al compilar codigo escrito en lenguaje C# el compilador genera codigo CIL que es el que en primera instancia es accedido por el JIT.
Claro que es una máquina virtual, formalmente es TODA una máquina virtual, ya comentaste muchas características y aun no te convences. No hablemos de JIT, optimización y generación de código que veo perfectamente que no es algo que domines.
Pero si quieres tocar el tema con gusto lo hacemos.
Memory management, Cross-compiling code, Resources management, optimization: Son características de una máquina virtual.
.NET y Mono son implemenciones de CIL segun el estandart
Mi inteligente amigo, y quien define esas IMPLEMENTACIONES? ( nuevamente es 'standard' ), sabes qué es lo que realmente hace tu 'CIL'? sabes de quién es parte este 'CIL'?
CLI Specification
Es lo mismo que decir que C++ no es un lenguaje sino una especificacion ANSI...
Ecma-334 : C# Especification
Ya leiste la especificación que te puse para que veas lo que NO contempla la especificación de C#? Sabes por qué Miguel de Icaza utilizó la especificación y construyó su propia implementación de la Máquina? Apuesto que no...
No, no son la sespecificaciones del lenguaje, son especificaciones del
J2EE
J2ME
J2SE
todos SDKs...
SDK es: Software Development Kit, es decir un conjunto de herramientas que sirven para desarrollar, sino tienes el JDK o el .NET FrameWork SDK lo unico que no puedes hacer es desarrollar, pero los programas pueden correr noemalmente asi que no son las especificaciones de java.. ni nada parecido.
Que son el conjunto de Frameworks y/o librerias que son utilizables por el lengueja de manera nativa,pero nada tiene que ver con el lenguaje.
Todos esos 'SDKs' que mencionaste son PARTE de las especificaciones de Java, y de manera mas concreta, son parte de las especificaciones para cada uno de esos SDKs... que cada uno cumple con nichos diferentes.
No me quedo claro nada mas de lo que ya habia dicho en mi post anterior.
Adicionalmente me quedo claro:
-que hablas demasiado
-que sabes tanto de .NET como yo de PERL ( incluso menos)
-Que eres un pelion buscapleitos, nadie estaba peliando hasta que llegaste con actitud provocadora... habia necesidad de eso...?
-Que me dejo provocar muy facilmente.
Hablo lo que es necesario para demostrar que lo que alguien presume que sabe, es demostrablemente FALSO.
En efecto, no soy desarrollador de .Net ( si lo hiciera se me cae el pene ), pero conozco la especificación, tal como la de Java.
No no vengo a buscar pleitos, quise aclarar algo que pareces estar muy convencido de que sabes y los demás creen que lo sabes.
Posiblemente si te dejas provocar, te exaltas muy fácil.
---Porque hicieron PERL .NET?
<sarcasm>Si seguramente es TAN conocido que la misma gente de Perl ya lo utiliza, es mas... creo que hay hasta un Kernel escrito con el verdad?</sarcasm>
Saludos,
PD.Lo que tampoco quiero es pelear, simplemente es un foro de opinión pública, y lo que aquí se proyecta es mi opinión. Tampoco con el afán de ofender, simplemente aclarar algunas cosas.