Для пущей экологичности предлагаю рассмотреть вариант найма в офис исключительно pollution-free разработчиков.

Практически неувольняемый так как является лицом компании.

Отличный пример, экс-CEO The Men’s Wearhouse, George Zimmer, даже будучи мемом «Guarantee It», не избежал участи получить пустую коробку для вещей в один прекрасный день.

Як варiнт — постоять у ЖД вокзала с транпарантом ООПэ от лукавого, пробудiтєсь для ФПэ. За оклад нє гарантiрую, но можна капелюха рядом положить.

Так тут же про цивилизацию, а не вспомогательный оутсорс, брезгливо сливаемый в страну третьего мира.

Всё правильно. Проблема не в инновациях. Их полно, написаных в стол. Проблема в инфраструктуре и производстве, для которых не решена проблема получения, хранения, и передачи нужных объёмов энергии. Возможно, как исчерпается нефть — весь наш эпичный прогресс и закончится. Ну и в бюрократии и вцелом устаревшей университетской системы. И в том, что она плохо работает в реалиях капитализма. Который сам по себе работает не идеально.

www.youtube.com/watch?v=yQLOIIeORhk

Есть ли какой-то раздел математики, с которым ты стопудов будешь получать больше, вне зависимости от технологии или проекта, просто за счет высокой производительности?

Теория категорий.

Никакое узкоспециализированное знание не есть универсальным.

Суть матана быть универсальным. См. абстарктную алгебру.

Стоит ли рассматривать это как инвестицию

Да.

в отсутствие интереса

Не стоит программировать.

Нет флага Гонконга на стандартной iOS клавиатуре?

В Coq очень мощная типизация, cutting edge. Но у него нет рантайма :) Программы на нём пишутся не для того чтобы их запускать, а чтобы проверять корректность их типов :)

just another layer of indirection

Возможно, не совсем понимаю о чём речь. А какой будет интерфейс у этого слоя, если заранее не известно, какой функционал потребуется добавлять?

Ага. Вот I и D для функциональщины особенно актуальны :)).

I — type classes или модули (их сигнатуры) в Caml, или трейты в Scala
O — final tagless, free monads и им подобные профункторы
D — сочетание вышеперечисленного, плюс наследование интерфейсов в type classes, GADT, и «функторах» ML.
Про S — вполне себе разумно учитывать проектируя как тип, так модуль, и конкретную функцию

Остается только L который в принципе логичен для любого языка с типизацией, вне зависимости от парадигмы.

Забавно что L меньше всего вопросов вызвал, но в целом и тут в языках без сабтайпинга можно притянуть наследование интерфейсов и type classes laws. Хотя в любом ML языке вполне себе сабтайпинг и вполне себе подстановка, разве что раннее связывание.

иероглифы лаконичней фонетического алфавита.

и именно по-этому от них никто не спешит отказываться, и вряд-ли когда-либо откажется. Скорее наоборот — стандартизируются emoji.

Типа если тебе нужно новый метод добавить во все существующие классы, и у каждого своя логика метода — никуда не убежишь ни в каком языке от написания N функций.

Да, но суть решения проблемы сделать это так, чтобы не затрагивать уже написаный код. И это возможно, но не в классическом ООП.

Что касается зав. типов, лично мои познания далеки от фундаментальных. А в рамках компетенции почему бы и нет, менторство вполне имеет место быть. Другое дело, мало кто за него стремится платить.

Про Coq. На нём верифицируют.

А это аргумент, пожалуй.

Вон на коке можно вполне рабочие программы писать

Увы, не можна ж. Оно кодогенерирует неэффективный код — раз. И без пруфов что сгенерированое соответствует спекам — два, доказывать, вроде, отдельно нужно. Плюс стоимость такой разработки будет раз в 20 дороже аналогичной на промышленном языке. Можно на ATS, но по цене разработки будет то же. Проще за разумное время или относительно стабильное но не очень шустрое ФП решение, или шустрое и нестабильное на императивщине.

JS не нужон =P

ООП не математика.

не могу согласиться. Если отказаться от приведения типа и апкастинга — вполне себе строго типизируется.

Т.е. одно только определение программы как однозначной декларации вычисления говорит о том, что это математика. Другое дело — оно имеет слабую выразительную силу, и не очень изящную реализацию.

Возможно, имелось в виду Smalltalk-style OOP, где упор делается на сообщения между объектами, а не на сами объекты, или, тем-более, классы. Которое, afaik, позже получило развитие в эрланговские акторы, весьма изящные в своей нише. При создании Java же, использовали «собственное ООП», что и привело к куче проблем. Хотя, может, это была и осознаная жертва ради какой-никакой — статической типизации.