Андрей Пронин

Когда начнешь понимать эту модель - сам же поймешь, зачем это надо. Если собираешься работать с сетями - то вряд ли ты будешь трогать уровни выше 4-ого (если тебе в плечи не вкинут обслугу какого-нибудь ng firewall'а). Понимание с практикой приходит. Если какие то примеры - вот обобщенный способ решения проблем на сети у рядового админа:
Большинство задач с проблемами на сети (даже маленькой, домашней) сводится к пониманию уровня, на котором проблема возникла - в домашней среде, у тебя, к примеру, есть модем, куда пришел сигнал от провайдера, за ним свич или вифи. У тебя пропал инет по вифи на телефоне. Ты начинаешь разбираться, где же проблема - смотришь, работает ли вифи, подключен ли телефон к роутеру - это 2 уровень OSI. Если там все ок, дальше смотришь подключен ли модем к провайдеру, есть ли пинги и т.п. наружу - это 3-ий уровень. Если там все ок - нужно смотреть прикладные уровни - к примеру, ДНС стал недоступен и это уже говорит о том, что проблема поднялась на прикладной уровень, в данном случае на 7-ой. А теперь попробуй масштабировать данную проблему хотя бы до офисного помещения, а потом добавь пару этажей. Прикинь, сколько у тебя будет коммутаторов, что будет маршрутизировать у тебя трафик в сети, будут ли файрволы. Вот так просто взять, и отключить по очереди устройства порой не то, что не логично, просто невозможно. И тебе нужно по максимуму ограничить потенциальное место возникновения проблем, и дать вощможность работать тем участкам, которые еще не пострадали. Вот здесь тебе нужно понимать, что за что цепляется, на каком уровне работает, как нужно группировать устройства, что бы максимально быстро проводить безопасные проверки как можно больших сегментов сети и т.д. А представь когда у тебя несколько офисов, или ты вообще инженер у провайдера?
Понимание модели OSI даст тебе понимание "вертикальной лесенки" движения трафика от клиентского приложения до кабеля - сверху вниз, и по нему дальше наружу или к другому приложению/сервису уже в обратном направлении - снизу вверх, поможет твою инфраструктуру положить на эту лесенку, и спокойно поуровнево по ней лазать, в случае необходимости. Один фиг, мне самому оно не сильно близко было, пока не поработал у провайдера - только на тех масштабах улеглось в голове, что без нее я делал такой ОГРОМНЫЙ объем лишней работы по траблшутингу и т.п. ранее, что теперь сам же и не понимаю, как можно не знать модель OSI, работая админом (как минимум упрощенную) )))

Модель OSI, это не конкретная "запчасть", которая может использоваться или не использоваться. Это основополагающий принцип того, как нужно думать о любом стеке любых протоколов, под каким углом на него смотреть )) Она потому и называется открытой моделью межсистемного обмена, (а не паттерном построения стека протоколов), что дает наиболее общую картину того, какие у протоколов в стеке могут быть характерные роли, и предлагает принцип, как это можно структурировать для понимания их взаимодействия друг с другом. И ее не нужно заучивать, ее нужно просто понять, сам принцип, и потом использовать это понимание для понимания других, уже конкретных вещей.

Посмотрите исходники nodejs, vue, или еще чего-нибудь, у чего тыщщи звезд.
Даже если окажется, что ООП там не идеальный - вы будете не в одиночестве. Найдутся тысячи единомышленников, готовых вести святую войну за единственно правильный ООП. (По крайней мере на этой неделе.)

Есть у вас, предположим, модель новости и её можно комментировать, для чего используется модель комментария. А через месяц эксплуатации сайта заказчик захотел ещё и статьи, и чтобы их тоже можно было комментировать. А потом ещё события всякие - театральные премьеры, киносеансы, концерты. И обзоры ресторанов маячат впереди. Вот только ForeignKey может указывать только на конкретную модель. Придётся либо все модели наследовать от общего корня, либо по новой писать модель комментариев и весь сопроводительный код для каждой комментируемой модели. И то, и другое - решение плохое. Выход - обобщённые отношения, позволяющие одну модель комментариев использовать для неопределённо большого круга заранее неизвестных моделей.

items = ['молоко', 'сыр', 'творог', 'кефир', 'яблоко']
for i, item in enumerate(items):
    print(i + 1, item)

ИМХО, Python.
Причина - предельная простота языка + набор готовых библиотек.
Парсите сайты параллельно через grab, который оперирует C-библиотеками (lxml) в удобной питоновой обертке.
Далее, если у вас данных <10 GB после парсинга - берите машинку с большим объемом оперативки, и используйте pandas +sklearn+hdf5 storage для хранения.
Если данных >10 GB - берите распределенный кластер и pyspark + hive для хранения и моделей
Java вам при решении data science задач не поможет - все равно python оперирует библиотеками с C-модулями и функциями (pandas/sklearn) или pyspark, это та же производительность Java, но в удобной обертке.

Если душа лежит к Java так и карты в руки, тем более, что она будет по-шустрее питона.
Преимущество питона в его простоте и лаконичности. Java же просто охренительно многословна.