Всё перечисленное — работа сеньорного программиста/product owner-а. тимлид — это человек, который раздает задачи программистам и отслеживает сроки их выполнения.
ФП — это слишком громко сказано :-). Чистое ФП достаточно сложно и в массы навряд ли пойдет.
Насчет объектов и реального мира, вот цитата из классика:
О проектировании иерархии классов говорили все, кому не лень — одни по делу, другие болтали «об имитации объектов реального мира».
Jeff Alger, «C++ for real programmers»
Проблемы копипаста в большинстве своем лучше решаются агрегацией.
В чистом ФП нет наследования и поэтому понятие полиморфизма к нему неприменимо. Вместо него использутся лямбды и абстрактные типы. Например, если в классическом ООП у нас есть interface Colored { Color getColor(); }, то в ФП это будет выглядеть так:
void drawColored <T>(T object, Function<T, Color> getColor) //getColor получает экземпляр T и возвращает его цвет
Придумали. Помните трех китов ООП? Котрые инкапсуляция, наследование и полиморфизм? Так вот, они устарели. Уже давно эксперты голосуют за агрегацию как основной инструмент повторного использования кода в ООП. Потом начали отказываться от концепции JavaBean — иммутабельные классы и чистые функции оказались выгодней.
Современный тренд — это композиция. Т.е. создание операторов, позволяющих естественным образом объединить два и более объектов или функций в один объект. Простейший пример — Stream API в джава, собирающий коллекцию и набор функций в новую коллекцию.
А Java, как язык, к сожалению, не очень хорошо подходит для композиции. Но я уверен, что в Java10 что-нибудь придумают.
10. Работа нервная и тяжелая, а оплачивается так же, как и сеньора с аналогичным опытом.
Обязанности тимлида совпадают с типичным обязанностями зама, вот только если в других областях деятельности зам может вырасти, то в IT пропасть между лидом и IT директором (или начальником отдела в крупных компаниях) очень велика.
Тем, что байт-код ВМ портабелен по определению — он запустится на любой платформе, на которую портировали интерпретатор этого байткода.
Портировать же приложение, пусть даже на очень качественном С, гораздо сложнее. Т.к. машина может иметь специфическую схему адресации, в исходниках могут быть баги, активирующиеся только после портирования, при портировании можно внести новые баги, в компиляторе могут быть свои баги...
А при использовании ВМ портировать, и, что важнее, тестировать нужно только виртуальную машину.
CLR либо только под винду, либо имеет серьезные проблемы с быстродействием
Go, насколько я знаю, использует заточенный под себя рантайм, т.е. другой язык на нем не сделаешь.
Не оказались. JVM жила, живет и будет жить, и вместе с ней будет жить Java как "нативный" язык программирования JVM.
Даже если в будущем изобретут язык, который во всех отношениях обгоняет текущие парадигмы программирования, в настоящее время есть только один качественный и эффективный рантайм со сборкой мусора — JVM.
VueJS идет в ту же сторону, но можно сделать лучше.
Например: https://www.mkyong.com/java/jackson-streaming-api-to-read-and-write-json/
http://www.martinreddy.net/gfx/MarsInfo
https://www.youtube.com/watch?v=mjzeP7hYyNo
https://www.youtube.com/watch?v=Y3n3c_8Nn2Y
2004 год
https://www.youtube.com/watch?v=E94Re7mL5vs
Насчет объектов и реального мира, вот цитата из классика:
О проектировании иерархии классов говорили все, кому не лень — одни по делу, другие болтали «об имитации объектов реального мира».
Jeff Alger, «C++ for real programmers»
Проблемы копипаста в большинстве своем лучше решаются агрегацией.
В чистом ФП нет наследования и поэтому понятие полиморфизма к нему неприменимо. Вместо него использутся лямбды и абстрактные типы. Например, если в классическом ООП у нас есть interface Colored { Color getColor(); }, то в ФП это будет выглядеть так:
void drawColored <T>(T object, Function<T, Color> getColor) //getColor получает экземпляр T и возвращает его цвет
Придумали. Помните трех китов ООП? Котрые инкапсуляция, наследование и полиморфизм? Так вот, они устарели. Уже давно эксперты голосуют за агрегацию как основной инструмент повторного использования кода в ООП. Потом начали отказываться от концепции JavaBean — иммутабельные классы и чистые функции оказались выгодней.
Современный тренд — это композиция. Т.е. создание операторов, позволяющих естественным образом объединить два и более объектов или функций в один объект. Простейший пример — Stream API в джава, собирающий коллекцию и набор функций в новую коллекцию.
А Java, как язык, к сожалению, не очень хорошо подходит для композиции. Но я уверен, что в Java10 что-нибудь придумают.
Обязанности тимлида совпадают с типичным обязанностями зама, вот только если в других областях деятельности зам может вырасти, то в IT пропасть между лидом и IT директором (или начальником отдела в крупных компаниях) очень велика.
Тут хорошо написано автором Скалы:
https://stackoverflow.com/questions/6085576/why-does-scala-choose-to-have-the-types-after-the-variable-names/6087167#6087167
Тем, что байт-код ВМ портабелен по определению — он запустится на любой платформе, на которую портировали интерпретатор этого байткода.
Портировать же приложение, пусть даже на очень качественном С, гораздо сложнее. Т.к. машина может иметь специфическую схему адресации, в исходниках могут быть баги, активирующиеся только после портирования, при портировании можно внести новые баги, в компиляторе могут быть свои баги...
А при использовании ВМ портировать, и, что важнее, тестировать нужно только виртуальную машину.
Виртуальная машина нужна не для гибкости, а для простоты портирования игр на другие платформы. Lost Vikings, к примеру, вышел еще и на сеге.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=csharpcore
CLR либо только под винду, либо имеет серьезные проблемы с быстродействием
Go, насколько я знаю, использует заточенный под себя рантайм, т.е. другой язык на нем не сделаешь.
Это классический способ отказать в сомнительной с точки зрения руководителя затее не говоря "нет".
Не оказались. JVM жила, живет и будет жить, и вместе с ней будет жить Java как "нативный" язык программирования JVM.
Даже если в будущем изобретут язык, который во всех отношениях обгоняет текущие парадигмы программирования, в настоящее время есть только один качественный и эффективный рантайм со сборкой мусора — JVM.