(Carrera) No puedo ser productivo debido al paradigma (o equipos) - Cambiar trabajo [cerrado]

Contextualizando:

Hola, tengo 25 años, y llevo 8 años trabajando como freelance. Principalmente trabajé con pilas: NodeJS, React, React Native y con TypeScript como superconjunto de pilas. Siempre me ha gustado programar, y siempre he estudiado lenguajes como: "C/C++/Rust/Go, Java/C#, Haskell, Python/Ruby, Elixir/Erlang, Clojure, Scala, Elm, PureScript.. . . " (a pesar de no programar profesionalmente en ellos, pero siempre estudié haciendo algunos proyectos personales). A pesar de ser generalista (porque soy freelancer) siempre me gustó entregar mi trabajo de la mejor manera, con código limpio, fácil y escalable.

Problema:

En este año, "dejé" la vida de freelancer y comencé a incursionar en el campo empresarial. Empecé a trabajar con otras personas y empecé a tener muchos "dolores de cabeza" al entender el trabajo de los demás (Usamos NODEJS) principalmente porque hay equipos que usan Vanilla JavaScript, otros TypeScript, algunos lo hacen de forma OO y otros más funcionales. .y eso es horrible para mí. Aunque no soy muy fanático de Java (y OO), al menos creo que está más organizado ya que siguen un patrón estricto que está completamente orientado a objetos (o en teoría debería serlo, después de que Java 8 introdujera lambdas).

Preguntas:

A pesar de tener un alto cargo en la empresa, a veces me preocupa no estar dando lo mejor de mí. No sé si es por costumbre, o si trabajar en equipo con OO y paradigmas mixtos (especialmente en JS) es realmente un lío.

He estado estudiando programación funcional durante mucho tiempo, y REALMENTE estoy buscando cambiar de trabajo para trabajar en un lenguaje más funcional (como Clojure o Elixir) porque puedo entender el código mucho mejor que una abstracción OO. (O al menos evitar el código incorrecto, creo)

¿Algún consejo para mí? ¡gracias!

Entiende que realmente te estás limitando a ti mismo. En la academia hay mucho uso de lenguajes funcionales y paradigmas. En el mundo real, OO destruyó funcional. El 99% de los trabajos usarán un paradigma OO. Puedo cambiar totalmente de trabajo porque no me gusta el idioma o las herramientas (se tuvo en cuenta en mi reciente cambio de trabajo), pero no obtener OO es algo en lo que debería trabajar. No lo vas a evitar en esta carrera.
He luchado sobre cómo decir esto de la manera más amable posible; pero, considerando la cantidad de tiempo que tiene en la industria, ¿está seguro de haber dominado el idioma en el que se encuentra? Puede tomar años de no estar completamente satisfecho con una solución para encontrar mejores patrones de resolución de problemas. Además, ¿cómo puede realmente evaluar los nuevos lenguajes, teniendo en cuenta que se encuentra en esa fase vertiginosa de ver "todos los beneficios" y "ninguno de los perjuicios" de los lenguajes Lambda? Descubre que su pensamiento limpio no es tan limpio como debería haber sido.

Respuestas (2)

Creo que está más organizado ya que siguen un patrón estricto que está completamente orientado a objetos (o en teoría debería serlo, después de que Java 8 introdujera lambdas)

Una oración como esta me hace preguntarme si sabes de lo que estás hablando. La orientación a objetos es un elemento básico de Java, pero las lambdas no son parte de la orientación a objetos, es parte del cálculo basado en Lambda, que a menudo está relacionado con Lisp o Scheme, lenguajes que generalmente carecen de objetos (a menos que decida implementarlos a través de medios no nativos ).

Estoy dispuesto a decir que un paradigma mixto de programación es más difícil que un solo paradigma, pero, sinceramente, JavaScript también está orientado a objetos, por lo que me pregunto dónde está surgiendo la combinación de paradigmas.

Me alegra saber que estás estudiando lenguajes basados ​​en lambda y que te gustan; pero, para ser honesto, probablemente no serás efectivo en eso hasta que dediques tu tiempo. Se necesitan años en un idioma para pasar de "ser capaz de hacer cosas" a "ser realmente hábil para hacer cosas".

En cuanto a la ayuda de Lambda Calculus a "evitar el código incorrecto", hay más malas noticias. El "código incorrecto" original fue escrito en las máquinas Lisp en los años 60. El código incorrecto existe en todos los paradigmas y, en la escala de Lambda Calculus, un paso en falso puede significar "arreglar esta lambda" o "reescribir todas las lambdas" en función de cómo la solución se integra en la base del código. Hay razones por las que este grupo lingüístico pasó de "poseer la mayor parte de la programación" a un nicho, y solo está recuperando terreno lentamente.

Entonces, reduciría la velocidad. Tal vez realmente estés donde crees que estás; pero, con el tipo de errores en su propia pregunta y los errores en lo que pueden proporcionar los nuevos lenguajes, estoy pensando que tiene la bendición de estar en una posición superior (y en su dominio, es probable que actúe en un nivel superior ) pero fuera de tu nicho, eres un poco demasiado confiado.

Tómate un tiempo y aprende cosas nuevas. El dominio de más de un nicho lleva tiempo y genera beneficios que son difíciles de medir. creo que vale la pena Solo creo (no tengo evidencia para respaldarlo) que estás hojeando las cosas nuevas, desilusionándote y luego abandonando el barco antes de que realmente conozcas el material. En unos meses más, es posible que te deshagas de las lambdas y pases al siguiente elemento genial que no dominas realmente. ¡En cualquier caso, buena suerte!

¡Hola, gracias por responder! Con Java 8 lambda, quise decir que: "No el java actual está 100% orientado a objetos", porque introdujeron lambda (que es funcional) de la versión 8 ", creo que fue mi error de escritura, lo que lo engañó para que lo malinterpretara, lo siento .
JavaScript no está orientado a objetos, es decir, actualmente con ES6 sí, pero originalmente está orientado a prototipos. En cuanto a la mezcla de paradigmas en los proyectos (que comenté): ¡No me refería al mismo proyecto! Porque aquí usamos JS para muchas cosas, y algunos equipos ejecutan algunos proyectos en Pure JS, otros prefieren usar TypeScript, otros usan un JS funcional (RamdaJS), y cuando ayudo a los proyectos de otros, "mezclo" el paradigma De todos modos, eso es lo que quise decir :)
Sí, hay problemas y código incorrecto en todos los idiomas, eso lo sé. Pero, me referí a lo siguiente: es más fácil equivocarse en OO que en algo funcional (opinión de novato) porque es más fácil de entender.
De todos modos, como dije, solo quería una forma de construir un código mejor y más simple de mantener, así que pregunté aquí, como no tengo experiencia con funcional, quería la opinión de aquellos que cambiaron de OO a funcional para saber cómo fue la transición. era . Incluso estaba buscando vacantes aquí: funcional.works-hub.com trabajos.braveclojure.com (Clojure fue solo un ejemplo funcional, podría ser Haskell o Elixir también) de todos modos, gracias por su tiempo
@srluccasonline Ah, sí. A menudo he escrito cosas que no se leen bien también. Veo que has editado la pregunta, también actualizaré la mía. Dicho esto, hay mucha orientación a objetos que no pude resolver sin problemas hasta años en ese paradigma. También puedo afirmar que hasta que tenga su primer programa grande en cálculo basado en Lambda, no habrá visto un código verdaderamente desordenado. Lambda lo ayuda a mantener la estructura que impone, pero puede ser tan bueno o tan malo como su propia capacidad para imponer disciplina en su código. Básicamente, con Lambda, es tan bueno (o malo) como puede ser.
@srluccasonline: Java siempre se ha considerado un lenguaje orientado a objetos. Si algo no está claro acerca de su pregunta, debe editarlo en lugar de enviar un comentario reconociendo que algo no estaba claro y aclarando ese algo en un comentario temporal.
@srluccasonline Además de los comentarios de Donald sobre Java, JavaScript también es ampliamente conocido por estar orientado a objetos. Es difícil encontrar una referencia que no diga "JavaScript es un lenguaje orientado a objetos basado en prototipos". El hecho de que uno use prototipos para hacer los objetos en lugar de constructores no los convierte en "no objetos".

En el mundo profesional, la programación orientada a objetos es el paradigma más común, pero, de manera realista, el desarrollo de software más moderno es multiparadigma . Recomendaría desarrollar su comprensión del paradigma orientado a objetos para complementar su conocimiento del paradigma funcional, pero no hay un paradigma que los gobierne a todos.

Y cualquier intento de tener "un paradigma para gobernarlos a todos" a menudo termina con "la oscuridad que los une": el proyecto falla o la complejidad se hace cargo a medida que el paradigma se inclina para lidiar con los problemas del mundo real.
(Carrera) No puedo ser productivo debido al paradigma (o equipos) - Cambiar trabajo [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v