#ITLife

Любовь и ненависть к фреймворкам

Фреймворки в программировании – это как мимолетный роман: они могут вдохновлять и поднимать тебе настроение, но в конечном итоге часто остаются с тобой только после отвратительного завтрака. 🤔 Давайте откровенно: с фреймворками мы переживаем целую гамму эмоций. Вот несколько стадий нашей любови:

1. Этап влюбленности:
- "С новым фреймворком я стану непобедим!" – это именно тот момент, когда мы надеваем розовые очки и каждый элемент кажется идеальным. Встретив стильные документы и «умные» функции, мы говорим: "Как же это круто!" 💖

2. Романтический запал:
- «Проект выйдет за неделю, Я освою его на раз-два!» – и тут наивный оптимизм встречается с реальностью. Через два дня мы уже только изучаем как настройка конфигурации может превратиться в сложную головоломку. И тут начинает приходить осознание: каждый казус – это не только твой, но и фреймворка.

3. Первая измена:
- "Почему каждая новая версия ломает всё что работало раньше?" – вот вопрос который мучает нас, как мука по утрам. Но отчаявшись мы идем искать "чела из стаковерфлоу", чтобы выполнить одну строку кода, пока пробуем "накатить" обновления.

4. Черная полоса:
- "Кто придумал этот фреймворк, и где я могу закопать его создателей?" – в этот момент мы начинаем проклинать всех, кто когда-либо касался клавиатуры, при этом осознавая что проблема, возможно, в самих нас. И если фреймворк запрещает мне писать приложения с минимальными усилиями, то я должен выставить его на всеобщее посмешище, рядом с недо-питонистами

5. Период смирения:
- "Наверняка, он всё равно его улучшит!" – тут как в отношений, мы идем на компромисс. Начинаем изучать документацию глубже, учим новые фреймворки, но и не забываем при этом залипать на обсуждениях о том, какой фреймворк все-таки лучший.

6. Собрание с сообществом:
- Фреймворки как вино: "А какой у вас любимый?" – и тут начинается самая настоящая битва уважаемых алкашей-программистов в дискуссиях с фанатами React, Vue и Angular! Но по сути все мы примерно одни и те же в плане разочарования и блаженства от изнасилования.

7. Финал:
- В итоге фреймворки – это как хорошие друзья: иногда они могут дико бесить, но без них ты понимаешь – жизнь была бы слишком скучной. Вот и выбирай: будет это любовь, ненависть или другой маневр, но одного не отнять – фреймворки сделали наше программирование ярким, хотя и утомительным! 🍷👩‍💻

#meme

Мне кажется вы стали забывать, кто тут настоящий хозяин программирования. Привыкли тут на меня лить помои и думаете я это просто так оставлю и ничего не сделаю вам в ответ?
Поздравляю, у вас получилось добиться полного разрыва моего клапана.

Да я код писал еще до того, как некоторые из вас под столом ползали; рефакторил такой чудовищный говнокод что вы даже представить себе не сможете; да у меня есть своя нейронка, которая обрабатывает столько информации, что Microsoft будет курить в сторонке.

И все потому что я - киберприрожденный. Установка ебашить код заложена в моих генах, клавиатура - мой меч, моя квалификация позволяет не только интерпретировать кофеин в машинные коды, но и параллельно разъебывать Мурыча и Соера. Таких избранных как я, существует единицы во всем мире и вы после всего этого смеете писать про меня всякие гадости? Тьфу на вас! Все вам рофлы, все вам приколы...

Ну все ребята, вы у меня допрыгались. Щас, щас я все вам выскажу....

#Python #meme

Вот взять, например, Петухончиков (Питонисты, Python):
Ну что вы маленькие, вжались в свои кресла? Страшно вам!? Терпите...

Все питухончики это неиронично отсталые орангутанги не сумевшие освоить нормальный ЯП; Вот что-то я не вижу как на вашем мониторе обучается нейросетка, хотя обмазались своим "компуктер скайнс" и убеждаете что как это все важно для индустрии в целом. Вечно хейтите С'и подобные языки, хотя сами тихо ночью плачете в подушку из-за индентации, ведь эту шляпу могло придумать только самое опущенное айтишное сознание; а все остальные молча решили схавать пробелы как часть синтаксиса языка.

Ой, а что там с многопоточностью? Все скриптики у питонистов невероятно медленные, а все потому что GIL может работать только в одном потоке, вот ведь не задача..? И я уже молчу про проблему релизов. Не обхаркал отказ в пользу второй версии Python только ленивый, а про мажорные обновления в Python 3 и несовместимости библиотек как-то принято молчать; к примеру:
Пакеты с пакетами того же матана и нейросеток. Лично для меня загадка что можно блять такого накодить в библиотеке для матана чтобы она была несовместима с интерпретатором 3.15 и 3.16

Всем же известно, что у каждого не уважающего себя питухонера установлено по 10-15 версий интерпретаторов одновременно.

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

#JavaScript #meme

Так, кто там у нас следующий? Ага, все тонконогие джавастриптезеры (JavaScipt)

Все они пропитаны комплексом неполноценных чмонек на столько, что из-за этого готовы затащить какую угодно херню в браузер лишь бы выглядеть понтово в глазах других разрабов. Начиная от различных компиляторов древних версий EcmaScript до всяких ёбо изобретений типа TypeScript и прочего говна, но как бы малятки не старались избавиться от позорного клейма - проблема в конечном итоге в том, что все их потоки компилируются в тормазутый JS.
Даже немного жалко этих ребят, ведь у этих смузихлёбов просто нету других альтернатив((( Ирония судьбы в том, что JS это единственный ЯП для покраски кнопок и ЯП, который может простить все ваши грязные, измазанные говном ручки в ошибках. Хочу сказать вам что другие разрабы настолько не уважают вас, что чисто по приколу чтобы поугарать над вами омежками, специально создают несовместимые стандарты, парсеры, интерпретаторы и в конечном итоге Браузеры.

А что вы им сделаете!? Да ничего! Вы можете только смотреть и не вмешиваться в процесс, тихонечко сидеть на кресле в углу комнаты

#C #meme

Сишники (С). Древнепердящие душнилы очевидности. По определению не могут быть моложе 50 лет; даже если тебе 18 и ты пишешь на С - на самом деле тебе полтинник, разлогинься, достояние пенсионного фонда. Деды настолько преисполнились в своём байтодрочестве что частенько забывают о стандартных принципах гигиены. А еще чаще других особей заявляют о том, что парадигма "n" не нужна, ну и с учетом их почтенного возраста скорее всего я мог им уступить место в автобусе

#Education

Вот знаете, существуют люди, которые не умеют гуглить информацию? Ну ничего, не грустите, этот гайд специально для вас, малятки:

Начнём с основ: Если ваш запрос выглядит как "dotnet работа дома", то, возможно, стоит уже подтянуть логику запросов. Не надо писать текстами в духе романов — лучше конкретика. Например: "установить dotnet на pc". Просто и ясно.

Минус-слова — ваши друзья: Если вас задолбали посторонние сайты и мусорная информация, используйте знак "минус". Пишете что-то вроде: "Лучший ноутбук для работы -игры". Всё, проблема решена, и вы увидите только то, что нужно.

Кавычки, или "я не знаю, как это называется": Если вы ищете что-то конкретное, например, точную фразу или название, обрамите её кавычками. Например: "цитата день рождения король лев". Не в кавычках — улетите в абстракцию, в кавычках — попадёте точно в цель.

Или это, или то (через палочку): Если ты до конца не уверен, как правильно называется то, что ищешь, пиши с вариантом через палочку: "лапша вок | ресторан". Гугл найдет и то, и это.

Не бойтесь уточнять: Сначала вводите общий запрос, а потом уточняйте. "Ремонт ноутбука", затем "ремонт ноутбука Иркутск", а потом уже "ремонт ноутбука Lenovo Иркутск недорого". Это как с фразами в жизни — чем конкретнее, тем лучше.

Смотрите на даты: Запомните, малятки, информация имеет срок годности. В 2024 году открывать гайд по "новым технологиям" от 2017-го — это как хлеб с плесенью жевать.

Используйте поиск по сайтам: Не знаете, как найти что-то конкретное на любимом сайте? Гуглите так: "site:сайт.ру ваш запрос". Вот так: "site
.com async python".

Ну всё, теперь вы профессиональный гуглер. Бегите, малыши, и просвещайтесь!

#meme

Рекомендации для всех двавастриптезеров:

Завтра ищете в интернете книжку "You Don’t Know JS" (серия книг) от Кайла Симпсона. Не переживайте, если что-то будет непонятно. Затем идете на MDN Web Docs изучать стандартную библиотеку JavaScript от корки до корки. Потом зубрите, именно, зубрите определения языка и стандартных библиотек — спецификацию ECMAScript, чтобы все термины и концепции отскакивали от зубов. Когда напишете свой первый промис и освоите асинхронное программирование, изучив теорию событий и коллбеков, скачиваете и изучаете любую библиотеку для работы с функциональным программированием, рекомендую Ramda или Lodash. Как только поймете, как использовать функции высшего порядка и композицию, можете идти дальше — вас ждет увлекательный мир функционального программирования в JavaScript.

Функции, замыкания, каррирование, монады, функторы, аппликативные функторы, промисы, генераторы, итераторы, реактивное программирование с RxJS, а также паттерны проектирования, такие как MVC, MVVM и Flux. Успех хиккующих выблѣдков или просто быдлокодеров типа Java-разработчиков, которые работают в крупных компаниях, не будут вас волновать, и уже через полгода вы будете получать такие предложения о работе,
что любой рекрутер будет в восторге от ваших навыков и опыта работы.

#AI

Про нейронки

Журналюги обожают хайпить на нейросетях, которые якобы заменят всех программистов. Но почему они упускают тот факт, что нейросетки могут решить лишь около 14% примитивных задач с 88% ошибок? (Что цифры именно такие — чистая случайность, математики, молчите).

Да, конечно, вот-вот и всех программистов заменят. Какие же журналисты дегенераты. ChatGPT уже может их заменить, ведь нести полную чушь они умеют и сейчас, а вот хорошо кодить — нет.

На самом деле, нейросетки были внедрены в инструментарий еще до нынешнего бума с GPT и Midjourney: в IntelliJ IDEA и Visual Studio ИИ появился еще в 2019 году (хотя до сих пор не научился писать код за людей). Copilot от GitHub был разработан примерно тогда же, когда моего деда в Берлине штурмовал другой дед и под капотом там сменились уже не одни рельсы.. И что мы имеем? Рабочий код пузырьковой сортировки, скопированный с просторов Bag Overflow, написанный ночью пьяным студентом педагогического колледжа.

Максимум, на что нейросети способны в обозримые 20 лет — это быть жалкими рабами для разработчиков. Человек, который в принципе не умеет писать код, не сможет обычными запросами реализовать продукт, да и даже один из модулей этого продукта. Есть один малюсенький нюанс, который все постоянно забывают: чтобы пользоваться этим инструментарии, нужно понимать, как и что делать, чтобы объяснить тупой нейросети все тонкости реализации. В противном случае, как говорится, "без внятного ТЗ результат — ХЗ".

А знаете, как называются люди, которые могут объяснить блядской машине, что именно надо делать? ПРОГРАММИСТЫ! Они просто используют язык программирования вместо простого человеческого. И я уж молчу про особенно сложные кейсы, которые требуют ответственности. Обожаю находчивость ИИ в выдумывании всяких несуществующих библиотек, которые, о чудо, идеально решают твою проблему. Осталось только установить все зависимости и написать три строчки кода. Как же это восхитительно(((

#Linux

Вот знаете, само ядро Linux — это настоящее произведение искусства в мире IT. Без него Интернет, каким мы его знаем, мог бы остаться на уровне локальной сети подземного игрового клуба Иркутска. Трудно представить себе сервер, который бы не работал на каком-нибудь дистрибутиве на базе GNU/Linux. Но, бля, когда дело доходит именно до GNU и всей этой шайки задротов-программистов-любителей десктопного ПО, то в репозиториях начинается сущий кошмар.

За 20 с лишним лет эти ребята не смогли создать ни одного нормального дистрибутива, который был бы лучше Windows или macOS для десктопов. Почему так? Сейчас объясню, и заодно поделюсь своим опытом использования Linux.

Если кому-то захочется сказать, что я идиот, то знайте: я управляю таксопарком из 5 виртуальных машин на Linux, за свою жизнь перенастроил столько серверов, что у терминала начинается течка между приглашением и именем пользователя. Именно на таких людях как я, держится весь грёбаный Интернет, позволяя гонять терабайты низкосортной порнухи и котиков за нано-секунды.

Проблема Linux'a одна, и она очень проста: ничего никогда не работает "из коробки". Ты не можешь просто накатить дистрибутив и начать им пользоваться — всегда найдутся проблемы, и их сначало будет дохрена, а потом опять дохрена. И так по кругу.

Можно подумать: "Ну ладно, поставил, пофиксил — и пользуешься хорошей ОС". Но проблема в том, что это бессмысленно. Linux не даёт никаких преимуществ, а наоборот, лишь проигрывает в возможностях и удобстве по сравнению с другими ОС.

Вот мой список проблем, с которыми я столкнулся за месяц:

1. Не работающие аппаратные элементы. Некоторые клавиши fn1-fn12 просто игнорируются, потому что драйверов или софта для них под Linux нет.

2. HiDPI-разрешение. ОС может и отображаться нормально, но софт — чаще всего нет. Где-то не подстроилось совсем, где-то — частично.

3. Pulseaudio. Звук завис? Перезапусти Pulseaudio. Воткнул наушники? Перезапусти Pulseaudio. Не работает Bluetooth? Угадайте... да, перезапусти Pulseaudio!

4. Графика. Представьте, в 2024 году ноутбук на Linux не умеет автоматически переключаться на дискретную видеокарту. Хочешь это сделать? Перезапусти Linux!

И это лишь верхушка айсберга...
Я могу продолжать этот список до бесконечности, но пост не резиновый. В общем, поставив себе Linux, ты не получишь ничего, кроме огромного ЧСВ до небес, а будешь только страдать.

Отдельно хочется упомянуть секту свидетелей обновлений: патчи на Linux приходят каждый день, и их блять надо устанавливать вручную через любимый терминал. В этом вашем Windows они хотя бы сваливаются раз в месяц и ставятся при перезагрузке, не доставая тебя каждый день.

И это даже не затрагивая софт. В большинстве случаев на Linux он портирован так, что даже макака из училища Усть-Залупинска справилась бы лучше.
Весь нужный софт для Linux можно спокойно запускать на Windows через WSL. Вторая версия полностью решила проблему совместимости, и нет такого дерьма, которое я бы не смог запустить на Windows.

Так что давайте, объясните мне, в чём я не прав, особенно жду ответ от секты пользователей Arch Linux — это те ещё "долбоёбы" в мире Linux, хотя куда уже хуже?

#startap #Education

Ну что, малята, предлагаю вам сделку: я делаю из вас долларовых миллиардеров, а вы потом скидываетесь мне по миллиончику. Идёт? Отлично.

Давайте я расскажу, как правильно делать стартап, чтобы потом жить на широкую ногу за счёт инвестиций какого-нибудь гоя из Кремниевой долины (хотя их называют инвесторами, но давайте смотреть правде в глаза).

Кто я такой, чтобы рассказывать про стартапы? Очевидно — успешный стартапер. Мы с ребятами запилили проект, продали его инвесторам и теперь сидим довольные на долларовой горке. Сейчас я являюсь Генеральным директором этой глобальной транснациональной компании (хотя благодаря санкциям это "транснациональная" пока только на словах). А вообще, я стал техническим директором просто потому, что громко заявил об этом на одном из собраний. Единственное сопротивление было от чувака, который делал нам архитектуру, но его жалкое "эээ..." я успешно проигнорировал. В итоге под моим управлением от одной до двух тысяч человек (скорее два, чем тысяча), но суть вы поняли.

Итак, как начинается стартап? Конечно, с идеи. Найти её несложно — каждый второй интернет-гений считает себя Илоном Маском, лопатой раздавая "революционные" идеи. И тут же эти "стартаперы" ищут людей, которые сделают всё за 50% от будущей прибыли (то есть 50% от нуля). Но ни один нормальный человек не будет участвовать в этом цирке, потому что в 99% случаев идея — дерьмо.

Можно, конечно, замотивировать свою команду работать на вас, но для этого придётся доказать, что идея рабочая. Это как у нас: генеральный купил у школьника за 500 рублей архитектуру проекта и уверял, что, если следовать плану, стартап взлетит. Так что перед тем как искать кодеров для разработки 3D-игры-хен..., убедитесь, что ваша идея не полное фуфло.

Следующий шаг — планирование. Обычно все его пропускают и потом мочатся в штанишки. Вначале все суперзамотивированы, готовы Луну сдвинуть, а спустя две недели программист Алёша перестаёт отвечать, дизайнер Валера занят ЕГЭ. Почему так происходит? Потому что вафлер, который всё это затеял, скипнул этап планирования.

Чтобы такого не случилось, нужно сесть с командой, обдумать минимальную функциональную версию продукта, составить график (RoadMap), чётко прописать дедлайны и задачи для всех. Чёткое ТЗ уменьшает вероятность, что ваш стартап улетит в трубу на 50%.

Теперь о разделении доходов. Старая русская поговорка "не дели шкуру неубитого медведя" — это полнейший бред. Наши предки не разбирались в стартапах, так что их советы тут не работают. Делить деньги нужно на берегу. И если кто-то думает, что деление "поровну" — хорошая идея, то я вас разочарую.

В стартапе кто-то тащит и продаёт идею, а кто-то верстает HTML. Разве это равноценный вклад? Конечно, нет. В нормальных местах платят зарплату, и в стартапах тоже, только чаще всего — опционами. Оценку стартапа вам дадут акселераторы, инкубаторы и прочие инвесторские заведения. Так что, если не хотите просрать всё, придётся ходить по ним и торговать лицом.

И последнее — управление. Это 70% успеха. Менеджмент решает, даже если у разработчиков всё валится из рук. Без сильного управленца стартап обречён на провал. Программистов, как бы сложно это ни было, можно заменить. А вот менеджмент — нет.

Так что, если чувствуете в себе силы стать "стартап-гендиром", готовьте свой план и свою команду.

#Education #Translation
Базовая база IT: интерпретация vs компиляция

Давайте немного углубимся в стародавние времена IT, когда деды программисты не дрались на форумах, а зарубались на тему трансляции кода. Этот вопрос до сих пор вызывает жаркие споры и является настоящим полем битвы для тех, кто любит посраться на тему производительности языков и их особенностей. Одним из таких легендарных срачей был момент, когда Рихтер заявлял, что в некоторых случаях C# оказывается производительнее C++. Давайте попробуем в этом разобраться.

Трансляция: с чего всё начинается

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

Интерпретация

В те времена, когда программисты тыкали перфокарты, первый метод трансляции был именно интерпретацией. По сути, каждая перфокарта содержала одну строку кода, которую комплюхтер тут же выполнял. Сейчас процесс интерпретации немного изменился, но суть осталась: программа на интерпретируемом языке (например, JavaScript или Python) исполняется построчно, программа-интерпретатор выполняет её "на лету", без создания отдельного исполняемого файла.

Плюсы и минусы интерпретации:

1. Программы легче переносить между разными архитектурами, так как ответственность за исполнение берёт на себя интерпретатор.

2. Интерпретируемые программы легче поддаются изменениям "на лету", так как нет необходимости их компилировать.

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

Компиляция

В противовес интерпретации возникла компиляция. Перфокарты никуда не делись, но код стал мощнее и структурированнее. Первым компилируемым языком был Fortran — тогда программисты уже использовали операторы ветвления и циклы, а не просто простейшие команды. Процесс компиляции позволял заранее прочитать весь код программы, проанализировать его, а затем превратить в исполнимый файл — так называемый бинарник.

Плюсы и минусы компиляции:

1. Производительность. Код компилируется для конкретной архитектуры, что даёт максимальную эффективность при исполнении.

2. Валидация ошибок. Компилятор заранее проверяет код, что даёт возможность отловить большинство ошибок до исполнения.

3. Код привязан к архитектуре — скомпилированная программа не сможет работать на другом типе процессора без дополнительной компиляции.

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

JIT-компиляция

Сегодня мы часто сталкиваемся с так называемой JIT-компиляцией (Just-In-Time). Этот подход комбинирует оба метода. Код программы компилируется в промежуточный байт-код, который затем интерпретируется на виртуальной машине (например, JVM для Java или CLR для C#). Это позволяет сохранять гибкость интерпретируемого кода, но при этом получать производительность, близкую к компилируемым языкам.

Плюсы JIT-компиляции:

1. Код можно использовать на разных архитектурах благодаря виртуальной машине, что делает программы кросс-платформенными.

2. После первого выполнения байт-код кэшируется и может использоваться повторно без повторной компиляции.

Пример языков с JIT-компиляцией: C#, Java, и даже JavaScript и Python, у которых под капотом сложные процессы компиляции в промежуточный байт-код.

#Translation

Почему всё это важно

Так как все эти процессы взаимодействуют на разных уровнях, дискуссии о том, какой язык производительнее, часто основаны на недопонимании того, как эти процессы работают на самом деле. Например, сравнивать C# и C++ в чистом виде — это немного абсурдно, потому что на высоком уровне и там, и там в дело вступает JIT, кеширование, оптимизация на уровне виртуальной машины и ещё куча других факторов. Но это не мешает IT-шникам устраивать локальные войны на эту тему.

Так что теперь вы готовы участвовать в высокоинтеллектуальных дебатах и отстаивать свою правоту, зная что такое интерпретация, компиляция и JIT!

#Education #Paradigms
Парадигмы написания кода:

Итак, тема парадигм программирования — это одна из тех, от которой, как говорится, даже видавшие виды айтишники могут спотыкнуться. Формальные определения часто заставляют мозг вскипеть, а преподаватели умудряются подавать материал так, что и сам черт не разберет. Но, давайте посмотрим на эту тему проще и с юмором.

Парадигма программирования — это просто набор правил, которые мы используем для написания кода. Это так скажем "философия" кода: как мы будем его строить и как наш комплюхтер это переварит. Мне, если честно, само слово "парадигма" не очень нравится и я бы с радостью заменил бы его на слово "модель", но тогда у вас потеряется мистический смысл.

Императивное программирование

Императивное программирование — это то, с чего начинали деды, и оно является основой для всех других парадигм. Тут всё просто: ты даешь машине чёткие инструкции, шаг за шагом. Написал алгоритм — машина исполнила. Это как давать указания, которые нужно строго выполнять.

Яркий пример — это тот же Assembler. Ты даешь машине прямые команды и говоришь, в каком регистре что должно быть. Управляющих конструкций особо нет, но зато есть go to (или jump), с помощью которой можно телепортироваться по коду. Это адовая хрень для любого программиста, потому что легко запутаться, особенно если код становится большим.

Структурное программирование

Всё изменилось, когда Эдсгер Дейкстра решил, что с этой ахинеей пора что-то делать. Он настолько устал от бардака с go to, что не зассал предложил разбивать код на логические части с помощью подпрограмм, циклов и управляющих конструкций. Так и появилась структурная парадигма, которая дала возможность разбивать код на более понятные блоки.

Теперь кодеры могли использовать подпрограммы и передавать управление туда, где это нужно, а не прыгать по коду, как блоха по ковру. Яркие примеры языков, которые поддерживают эту парадигму — это "C", Pascal и Basic.
"C" стал настоящим прорывом, потому что его использовали для более сложных систем, чем просто написание одной большой программы.

Объектно-Ориентированное Программирование (ООП)

Когда программисты сидели и кодили на структурных языках, они заметили интересный эффект: если переменные из подпрограмм не убирать сразу из памяти, то их можно использовать и в других подпрограммах. Так случайно и родилась ООП-парадигма.

Смысл ООП в том, что программирование теперь вращается вокруг объектов и классов. Объекты — это конкретные экземпляры классов, которые могут иметь свои данные и методы. А классы можно рассматривать как чертежи для создания объектов.

ООП дала нам такие плюшки как:

1. Инкапсуляция — скрытие деталей реализации от других частей программы.

2. Наследование — возможность создавать новые классы на основе существующих.

3. Полиморфизм — это когда один и тот же метод может вести себя по-разному в зависимости от того, какой объект его вызывает.

Благодаря этому ООП взлетело на всех фронтах, и такие языки как Java, C++, и более новые, такие как Python, активно используют эту парадигму.

Комбинирование парадигм

Что интересно, современные языки программирования редко придерживаются одной единственной парадигмы. Они часто сочетают несколько подходов, чтобы дать больше гибкости разработчикам. Например:

Java — это мощный объектно-ориентированный язык, но он также поддерживает элементы императивного программирования.

Python — тут можно писать как в стиле ООП, так и в процедурном стиле, что даёт свободу выбора для разработчика.

PHP — до версии 4 был чисто процедурным, но позже медленно, но уверенно переключился в сторону ООП. Тем не менее, никто не мешает писать в нём и процедурный код, что и порождает смесь стилей в проектах.

#Education #Paradigms

Другие интересные парадигмы

Есть и другие парадигмы, которые тоже достойны упоминания:

Функциональное программирование — его основная идея в том, что всё представляется в виде функций. Функции могут передаваться как параметры другим функциям, а также возвращать другие функции. Этот стиль активно используют в языках вроде Haskell или даже в тех же JavaScript и Python, где поддерживаются функциональные элементы.

Декларативное программирование — тут ты не пишешь, как выполнить задачу, а говоришь, что нужно сделать. Пример: SQL — ты просто описываешь, какие данные тебе нужны, а база данных уже сама решает, как их получить.


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

#JavaScript

Я чувствую, что в моих словах горит священный огонь защитника JavaScript, и, честно говоря, сложно не согласиться с собой. Весь этот старперский снобизм по отношению к JS уже давно отдает плесенью двухтысячных офисов с Windows XP и IE6. Давайте сразу к делу — JavaScript это гораздо больше, чем просто анимации и подсветка кнопочек.

1. Инфраструктура — мирового уровня

Первое, что нужно выдвинуть в защиту JavaScript, — это его невероятно развитая экосистема. npm — крупнейший репозиторий пакетов в мире. Хочешь фреймворк для чего угодно? Есть React, Vue, Angular. Хочешь сервер на JavaScript? Вот тебе Node.js с асинхронной магией, которая заставляет любой backend пахать, как швейцарские часы.

Плюс, весь набор инструментов разработки — Webpack, Rollup, Parcel и десятки других сборщиков, которые позволяют поддерживать этот язык и адаптировать его под любую задачу. Babel и TypeScript делают то, что критики из "галерных офисов" вообще не готовы принять: они превращают JavaScript в "чемпионский комбайн", который может решать задачи как на фронте, так и на бэке с невероятной гибкостью.

2. Асинхронность — прямо из коробки

JavaScript буквально изначально асинхронен, и это один из его самых сладких плюсов. Промисы, async/await — это магия, которая избавляет тебя от заморочек с потоками, блокировками и прочим адом, который в других языках делает разработку асинхронных приложений настоящей головной болью. Вы не мучаетесь с многопоточностью как в Java или C#, вам не нужно следить за сотнями нюансов потокобезопасности. JavaScript делает асинхронное программирование естественным.

И не забывайте про серверный JS — тот же Node.js вообще строится на этой философии. Никакого забивания процессора, никакой необходимости в десяти серверах, чтобы обслуживать простую задачу — всё работает эффективно и быстро.

3. Динамическая типизация — свобода самовыражения

Вот тут начинается самое сладкое — динамическая типизация. Её любят хейтить те, кто застрял в статически типизированных языках вроде Java или C++, где ты должен каждый раз танцевать с бубном над типами и полиморфизмом. Но в JavaScript ты можешь творить без тормозов.

Да, кто-то скажет: "Но контроль над типами же!" — ну да, как же без старой песни про типизацию. Но это в основном страх тех, кто привык к строгости компилятора. Когда ты работаешь в JavaScript, ты получаешь свободу. Хочешь быстро закидать логику на коленке? Пожалуйста. Надо динамически подогнать структуры данных? Это не проблема. Не надо перегружать методы, не надо жонглировать с дженериками и шаблонами, ты просто пишешь код и получаешь результат.

4. Функциональные фичи — где надо и как надо

JavaScript не только про императивщину, он прекрасно поддерживает функциональный стиль. И это не просто поддержка, а реальные фичи, которые делают жизнь легче: map, reduce, filter — с такими функциями вы можете манипулировать данными как бог. Вы можете создавать чистые функции, использовать замыкания, строить цепочки вызовов, как будто играешь в сложную игру с Lego.

При этом тебе не обязательно уходить в глубокий функциональный подход как в Haskell. В JavaScript всё работает гибко: хочешь применять функциональные концепции — пожалуйста, не хочешь — можешь писать более императивный код. Эдакий гибрид, который подстроится под твои задачи.

5. Универсальность и популярность

А теперь самое главное: JavaScript сегодня — это язык номер один по популярности и применению. Это язык, который правит на фронтенде, захватывает бэкенд через Node.js и вообще проникает повсюду. Ты пишешь один язык и можешь строить полноценные веб-приложения с фронта до бэка. Это мощь, это гибкость, и это невозможно не признать.

#JavaScript

Критика JavaScript как "недоязыка" звучит особенно смешно на фоне его повсеместного использования в крупных корпорациях, стартапах и высокотехнологичных проектах. Этот язык, который начали с анимаций для кнопочек, сейчас способен строить сложные распределённые системы, и это уже доказано множеством успешных проектов.

Ну и что на это ответить тем, кто до сих пор считает, что JavaScript — это "детский" язык? Да они просто отстали от времени. Те, кто сидят в своих галерах и жалуются на невозможность понять динамическую типизацию или асинхронность, видимо, просто не хотят выходить из своей зоны комфорта.

JS — это про гибкость, свободу и реальную мощь, которой можно воспользоваться прямо сейчас. Да, он не идеален. Да, у него есть свои особенности и косяки (какой язык их не имеет?). Но если тебе нужно разрабатывать современные приложения, писать один язык для всего стека, и при этом не тратить годы на обучение каждому фреймворку — JavaScript твой выбор.

Ну, а те, кто продолжают хейтить, могут продолжать сидеть в своих статически типизированных замках. Мы будем писать и развиваться, потому что JavaScript — это про будущее.

#Linux #OS

Почему Питер на Linux — это не всегда сила, а иногда просто комедия

Давайте разберемся, почему в мире разработки так важна унификация, и почему "Питер", который сидит на своей убунте, может быть не таким уж крутым, как ему кажется.

Работая с тремя операционными системами — Ubuntu, Windows и macOS — я пришел к выводу, что нанимают разработчиков не для того, чтобы они настраивали свои убунты под себя, а чтобы решали реальные проблемы бизнеса. В большинстве случаев нам дают Windows или macOS ноуты с уже частично настроенными инструментами, а что-то устанавливаем под конкретный проект. И, о чудо, у компаний есть гайды, как все это делать!

Зачем это нужно? Чтобы у всех в команде было "как у всех". Понимаете? Чтобы баги воспроизводились одинаково. А не так, чтобы у "Питера" на Linux что-то отвалилось, а остальные на Windows сидят и не могут воспроизвести баг. Это же как в комедии: "У кого-то сломался велосипед, а остальные на машинах — и что теперь делать?"

Но вот "Питер" — настоящий программист, да? Он же на Linux сидит! Мощь! 😂😂😂 В его глазах это как медаль за отвагу. Но давайте будем честными: сколько комбинаций клавиш в vi, vim или neovim нужно запомнить, чтобы просто редактировать текст? 999+? Зачем? Чтобы потом сидеть и настраивать свой vim так, чтобы он хоть немного напоминал JetBrains IDE?

Нам дали унифицированный способ взаимодействия с текстом — JetBrains IDE, курсор, мышь и клавиатура. Но некоторые считают, что это для слабаков. 😂😂😂

В конце концов, не важно, насколько быстро ты печатаешь, если думать получается медленно. Это математика, друзья. Так что, может, стоит оставить "Питера" с его Linux и вернуться к реальным задачам?

Ведь в мире разработки главное — это не операционная система, а результат. А если "Питер" не может воспроизвести баг, то, возможно, ему стоит задуматься, кто на самом деле "слабак". 😄

#AI

Да, я тут сайд-проект пишу с помощью JetBrains AI. Знаете, это как общаться с умным другом, который иногда забывает, что у него есть мозг. Главное — писать явно и максимально точно то, что хочешь. А он, как будто на стероидах, генерирует по 100 строк кода, как будто у него есть личный ассистент с дипломом.

Но вот беда: многие люди не умеют с ним общаться. Слышал, как кто-то восклицает: "Ваш ИИ тупой, неправильно отвечает на вопрос!" А потом смотришь на их запрос и думаешь: "Серьезно? 'Сделай программу скачивания фильмов' — это всё, что ты можешь придумать?" Это как если бы ты пришёл в ресторан и заказал "еду", а потом жаловался, что тебе принесли что-то странное.

Иногда ИИ действительно выдает нелогичные вещи, но стоит просто сказать: "Эй, не делай так!" — и он, как послушный щенок, исправляется.

Почему не очень просить его написать код? Да потому что это всё равно что просить соседа, который не умеет готовить, сделать тебе ужин. Ты же не будешь удивляться, если он подаст тебе макароны с вареньем! Но, если честно, я прошу и меня это устраивает. Да, иногда приходится его поправлять, как маленького ребёнка, который только учится ходить. Но это часть процесса, и, в конце концов, у меня мало претензий к последней платной модели GPT-4. Она, похоже, действительно "ушла далеко" — как будто на курсы повышения квалификации для ИИ.

Так что, ребята, учитесь формулировать свои запросы! И помните: ИИ — это не волшебная палочка, а скорее ваш умный, но немного рассеянный друг, который иногда нуждается в подсказках.

#Programming

Все языки программирования — говно

Аксиома Эксобара, касающаяся языков программирования, долго не давала мне покоя, и, как объективный и беспристрастный IT-специалист, могу смело заявить: все языки программирования — говно.

Каждый из этих ваших "наборов инструкций и операторов" полон недостатков, и начнём мы, конечно, с JavaScript:

Как бы мы ни любили JS, нужно признать: этот язык — далеко не идеал. У него отсутствует четкая структура, а стандарты его столь же туманны, как утренний кофе после бессонной ночи. Прототипное ООП? Да это же настоящий музей костылей! Использование его для backend программирования — вообще анекдот. Но при всём этом, несмотря на несуразные корни и проблемы с ООП, JavaScript — это настоящий "швейцарский нож". Он проникает везде, и его универсальность — его главный козырь.

PHP

С PHP все немного иначе. Это словно друг из детства, который хоть и не самый умный, но всегда готов прийти на помощь. В нём есть всё, чтобы быстро собрать сайт "на коленке". Хотя давайте будем честными: чем глубже вы погружаетесь в проекты на PHP, тем больше встречаете кривого и непонятного кода от старых версий.

Python

Пользователи Python с их бесконечными спорами о табах и пробелах заслуживают отдельного внимания. Без фигурных скобок писать код как-то даже странно. И да, сообщество активно обсуждает, как правильно делать отступы, вместо того чтобы решать насущные проблемы производительности или многопоточности. Python хорош для скриптов и автоматизации, но как только речь заходит о более сложных проектах, вы сталкиваетесь с множеством компромиссов и костылей.

Java

Java — это как старая машина, которая по-прежнему работает, но требует слишком много ресурсов. 3 миллиарда устройств? Да, возможно. Но все знают, что Java медленно движется на старом коде и зачастую является излишне тяжёлой. Её прожорливость и неповоротливость — это испытание для любого разработчика. Каждый раз, когда вы запускаете Android Studio, вам хочется выключить обогрев в комнате — так сильно она греет наше очко.

C#

C# — это язык, который пытается быть универсальным, но порой в этом желании вы буквально тонете в типах и абстракциях. Вместо решения прикладных задач вы увязаете в типах, наследовании и бесконечных абстракциях. Это словно лабиринт, в котором, чтобы решить простую задачу, приходится блуждать, параллельно слушая советы всевозможных "гуру".


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

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

#News

Почему в чехарде с Discord виноват YouTube?

За последние недели развернулась нехилая Санта-Барбара по поводу блокировок. В СМИ уже как неделю вбрасываются сообщения, что Дискорд «ВОТ-ВОТ разблокируют». Его ж даже убрали с базы данных РКН, а сервис че-т все равно не запускается с российских айпишников.

Акт 1 Блокировку видишь? А она есть

Для начала вспомним эпопею с (не)блокировкой YouTube. Это было новое для нас явление. К обычным официальным блокировкам мы уже привыкли. Но в случае с Ютубом было все иначе. Официального предписания не было. Чиновники путались в мотивировке: то дело в оборудовании, то в злом Госдепе. А блокировка осуществлялась избирательным образом только на домашний интернет. Да и даже здесь итог отличался от провайдера к провайдеру.

А вот уже это запустило акт 2

Акт 2 Рыночек против деградации

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

Мол чего-то у одних замедляют Ютубы, а у других нет. Вы дискриминируете рынок. Это действие переносит нас в Акт 3

Акт 3 Понятные правила, понятные немногим

Когда я учился в школе, бывало такое, что учительница ставила двум работам разные оценки за одинаковые ошибки. Одному 5-, а другому 4. Хотя оба в одном месте пропустили запятую. И когда дискриминированный шел к учителю разбираться, учитель, разумеется свой просчет признать не мог. Это западло. Но не западло было уровнять результат обоим ученикам в меньшую сторону. Теперь у нас две работы с оценкой 4. И здесь я ожидал что-то подобное.

Но Роскомнадзор изобретает третий вариант. Он говорит, что просто не обязан отвечать на вопросы учеников.

11 октября, через пару недель после обращения «учеников» , РКН разрабатывает проект приказа, по которому может замедлять вообще что захочет через внесудебное решение Генпрокуратуры. А т.к. последние обладают привилегией тайны, т.е. ничего никому не объяснять и информировать, то подобная фича распространяется и на РКН. РКН назвал это «управлением сетями». В общем, не блокировка без суда и следствия, а управление сетями. Записываем в словарик.

Ну ладно, мы поняли, что коммуникация с людьми не сильная сторона великого блокиратора. Ну хотя бы на сайте РКН можем отслеживать, что нам можно смотреть, а что нет

Ну… не совсем

Акт 4 Продолжение давно идущего тренда

Когда СМИ писали, что Дискорд вот-вот разблокируют, они основывали свое предположение на исчезновении из базы РКН домена. И в целом, предположили адекватно. Но кто ж знал, что РКН втихую изменит механизм работы этой базы данных. Теперь может быть такое, что указывать надо не домен, а конкретную страницу, где размещен запрещенный материал. Страницу. В дискорде. Конкретную.

Как узнать, что именно запрещено? Ну это в списках Роскомнадзора

А как посмотреть эти списки?

¯\_(ツ)_/¯

Вот и получается, что Дискорда в базе нет, но он заблокирован. Ютуба в базе нет, но он частично замедлен.

Мы сейчас с вами входим в новую реальность, когда проверить блокировку ресурса сможем только своим лбом. Если по ходу дела спотыкаемся, а сервис открывается с помощью средств починки, значит заблочил РКН. Почему? За что? Что именно?
Знать не положено

Коммуникация 11/10

#Education #Python

Если решил учить Python, браток, добро пожаловать в хату питонистов. Тут, знаешь ли, свои правила — на базу не по фене ботать не получится, придётся научиться шарить не только за циклы и функции, но и за то, как правильно двигать по жизни.

Первое, что тебе надо понять: заходишь в проект — заходи с умом. Если ты тут по красивую жизнь пришёл и думаешь, что Python'чик тебя на райские пет-проектики выведет — хаха, держи карман шире! Ты теперь на зоне, и тут такие штуки, как баги, костыли и дедлайны — как масти в картах, всегда с тобой.

Сокамерники могут быть разные — от джунов до сеньоров, но знай: дедуля твой SRP — это как устав. Ты чётко должен всем сказать: «Мужики, у меня одна обязанность, или я тут дебагом занимаюсь, или код пилю. В две работы вписываться не буду, с пониманием отнеситесь». А за «Open-Closed» лучше молчи, это вам не на воле — никто расширяться не хочет, максимум, что тебя ждёт — это лишний таск на шею.

В Python всё просто: задачку вкатили — решай. Только ты знаешь, что всегда будет два стула. На одном — «геморойная оптимизация кода», на другом — «залезть в чужие костыли и понять, кто тут батя». Вот и думай, на какой сесть.

Короче, Python — штука гибкая, но учись правильно раскидывать по камере свои задачи. Не тупи, асинхронку тут все уважают, потому что никто не хочет чтобы система висла, как лох-javaScript'езер. Тебе ж не охота стать «тем, кто завалил проект», да?

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