Психологическая типизация — важный и популярный вопрос психологии
Существенный прогресс сделал в нём Карл Юнг, написав в результате работу "Психологические типы". Психологические типы — это, в целом, в массе самый увлекательный вопрос психологии. Каждому хочется знать, к какому типу (всё равно в какой системе) он относится.
В этом плане психотерапия любого классического подхода, отказывающаяся от диагнозов (для того, чтобы не "навешивать ярлык" на клиента и тем самым не сужать ожидания масштаба и качества возможных изменений), проигрывает в борьбе за внимание массового потребителя любому поп-психологическому подходу.
Но здесь хотел отметить, что человек, который верит в систему психологических типов (любую — например, в систему знаков зодиака) выраженно эффективней в коммуникации, чем человек, не имеющий никакого механизма "диагностировать" окружающих — поскольку у первого, в отличие от второго, есть твёрдый базис для убеждённости в том, что он может так или иначе воздействовать на товарищей. А наличие данной убеждённости уже, по сути, 50% процентов дела (хоть и не 100%).
Соционика идёт по этому же пути — это такая же стилизованная "а-ля психологос" система "знаков зодиака" без научного базиса, но которая вполне работает по вышеуказанной причине.
Плохая система типов (если каждый тип хоть немного позитивен и жизнеутверждающ, конечно) лучше никакой; а хорошая лучше, чем плохая.
Хорошая система типов опирается на некий первичный объективный феномен и наворачивает теорию уже поверх наблюдаемых фактов. В этом плане пресловутая классификация "визуал - аудиал - кинестетик", которая уже давно "пошла в народ", подкреплённая наблюдением за боковыми движениям глаз, конечно, на два порядка лучше "соционик". Хоть и, в сущности, всё равно не дотягивает до строгой научности: взаимосвязь движений глаз и систем восприятия не столь простая (и что такое "систем восприятия" далеко не тривиально расписать).
А эталонных систем психологических типов, к которым не было бы очевидных замечаний, пожалуй, и нет. Это, конечно, является одной из ряда фундаментальных недоработок психологии как научной дисциплины.
#psychology
Существенный прогресс сделал в нём Карл Юнг, написав в результате работу "Психологические типы". Психологические типы — это, в целом, в массе самый увлекательный вопрос психологии. Каждому хочется знать, к какому типу (всё равно в какой системе) он относится.
В этом плане психотерапия любого классического подхода, отказывающаяся от диагнозов (для того, чтобы не "навешивать ярлык" на клиента и тем самым не сужать ожидания масштаба и качества возможных изменений), проигрывает в борьбе за внимание массового потребителя любому поп-психологическому подходу.
Но здесь хотел отметить, что человек, который верит в систему психологических типов (любую — например, в систему знаков зодиака) выраженно эффективней в коммуникации, чем человек, не имеющий никакого механизма "диагностировать" окружающих — поскольку у первого, в отличие от второго, есть твёрдый базис для убеждённости в том, что он может так или иначе воздействовать на товарищей. А наличие данной убеждённости уже, по сути, 50% процентов дела (хоть и не 100%).
Соционика идёт по этому же пути — это такая же стилизованная "а-ля психологос" система "знаков зодиака" без научного базиса, но которая вполне работает по вышеуказанной причине.
Плохая система типов (если каждый тип хоть немного позитивен и жизнеутверждающ, конечно) лучше никакой; а хорошая лучше, чем плохая.
Хорошая система типов опирается на некий первичный объективный феномен и наворачивает теорию уже поверх наблюдаемых фактов. В этом плане пресловутая классификация "визуал - аудиал - кинестетик", которая уже давно "пошла в народ", подкреплённая наблюдением за боковыми движениям глаз, конечно, на два порядка лучше "соционик". Хоть и, в сущности, всё равно не дотягивает до строгой научности: взаимосвязь движений глаз и систем восприятия не столь простая (и что такое "систем восприятия" далеко не тривиально расписать).
А эталонных систем психологических типов, к которым не было бы очевидных замечаний, пожалуй, и нет. Это, конечно, является одной из ряда фундаментальных недоработок психологии как научной дисциплины.
#psychology
Парные темы
Считается, что цель СМИ — заморочить обывателю голову какой-то неправильной информацией, чтобы он не смог докопаться до правильной. Под правильной обычно подразумевают научную. К сожалению, машина производства научного знания работает в целом по тем же законам, что и СМИ, и везде требуется предметное разбирательство. Информация из любого источника может быть ценной и любой "авторитетный" источник может врать.
На самом деле, цель СМИ — создать тематическую оппозицию, где одна тема прикрывает другую (и обе ложные).
Последние дни обсуждают защиту диссертации по гомеопатии. Мол, гомеопатия, это лженаука, а тут как бы учёные со степенями защищают диссертации, причём демонстративно нагло. Используя принцип "парных тем" легко вычислить бенефициара вопроса — это, конечно, "доказательная медицина" (правильней было бы говорить о "медицине, движимой статистикой" — "statistically driven medicine"). Гомеопатия это очень соблазнительная тема для того, чтобы служить отвратительной красочной картиной, маскирующей дырку в стене, которой является "докмед".
Любая полемика на темы, включённые в разрекламированную оппозицию, будет натыкаться на радикальное непонимание. Например, аккуратные соображения касательно ограниченной применимости докмеда к качеству жизни конкретного среднего человека (по ряду очевидных и известных причин), будут натыкаться на ответ "а-а, ну так ты гомеопат".
Конечно, верно и обратное: аккуратные соображения о том, что действующий эффект не может объясняться степенью разведения до полного отсутствия в растворе одной молекулы действующего вещества, будут натыкаться на ответ "а-а, так ты аллопат" :) Ну или что-то вроде того (к сожалению, не участвовал в полемике с гомеопатами, в отличие от докмедовцев).
То, что обе диспутирующие стороны являются в сущности сектантами, ограничивающими самим фактом наличия своей полемики развитие познания в широком смысле и науки в конкретно-прикладном, обычно остаётся за пределом внимания обывателя, т. к. он сфокусирован только на одном полюсе искусственно созданной дихотомии.
Как же быть, как же нащупать "золотую середину"? Единственный вариант — пытаться найти некий общие принципы, инварианты знания, своеобразные "законы сохранения энергии" во всех интересующих сферах.
Закон парных тем — один из таких.
Конечно, в отличие от физических законов, он может поменяться: если все станут шибко умные и реагировать со скепсисом как бы "на шаг вперёд" (если сегодня пудрят мозги бузиной в огороде, то мы как бы заранее начнём сомневаться в дядьке в известном городе), то стейкхолдеры начнут работать "на два шага вперёд". Но, с другой стороны, за триста лет такого не произошло, так что ещё минимум лет сто в запасе есть.
Как в том анекдоте: "А что будет, если все будут такими умными, как вы?" - "Согласно статистике, все не будут".
#psychology
Считается, что цель СМИ — заморочить обывателю голову какой-то неправильной информацией, чтобы он не смог докопаться до правильной. Под правильной обычно подразумевают научную. К сожалению, машина производства научного знания работает в целом по тем же законам, что и СМИ, и везде требуется предметное разбирательство. Информация из любого источника может быть ценной и любой "авторитетный" источник может врать.
На самом деле, цель СМИ — создать тематическую оппозицию, где одна тема прикрывает другую (и обе ложные).
Последние дни обсуждают защиту диссертации по гомеопатии. Мол, гомеопатия, это лженаука, а тут как бы учёные со степенями защищают диссертации, причём демонстративно нагло. Используя принцип "парных тем" легко вычислить бенефициара вопроса — это, конечно, "доказательная медицина" (правильней было бы говорить о "медицине, движимой статистикой" — "statistically driven medicine"). Гомеопатия это очень соблазнительная тема для того, чтобы служить отвратительной красочной картиной, маскирующей дырку в стене, которой является "докмед".
Любая полемика на темы, включённые в разрекламированную оппозицию, будет натыкаться на радикальное непонимание. Например, аккуратные соображения касательно ограниченной применимости докмеда к качеству жизни конкретного среднего человека (по ряду очевидных и известных причин), будут натыкаться на ответ "а-а, ну так ты гомеопат".
Конечно, верно и обратное: аккуратные соображения о том, что действующий эффект не может объясняться степенью разведения до полного отсутствия в растворе одной молекулы действующего вещества, будут натыкаться на ответ "а-а, так ты аллопат" :) Ну или что-то вроде того (к сожалению, не участвовал в полемике с гомеопатами, в отличие от докмедовцев).
То, что обе диспутирующие стороны являются в сущности сектантами, ограничивающими самим фактом наличия своей полемики развитие познания в широком смысле и науки в конкретно-прикладном, обычно остаётся за пределом внимания обывателя, т. к. он сфокусирован только на одном полюсе искусственно созданной дихотомии.
Как же быть, как же нащупать "золотую середину"? Единственный вариант — пытаться найти некий общие принципы, инварианты знания, своеобразные "законы сохранения энергии" во всех интересующих сферах.
Закон парных тем — один из таких.
Конечно, в отличие от физических законов, он может поменяться: если все станут шибко умные и реагировать со скепсисом как бы "на шаг вперёд" (если сегодня пудрят мозги бузиной в огороде, то мы как бы заранее начнём сомневаться в дядьке в известном городе), то стейкхолдеры начнут работать "на два шага вперёд". Но, с другой стороны, за триста лет такого не произошло, так что ещё минимум лет сто в запасе есть.
Как в том анекдоте: "А что будет, если все будут такими умными, как вы?" - "Согласно статистике, все не будут".
#psychology
Про "софт-скиллы"
В целом следует отличать три типа софт-скиллов:
1. Личное умение (и набор навыков) для достижения социальных ("быть обеспеченным"), коммуникативных ("добиться повышения зарплаты от начальника") и предметных ("быстро придумывать правильную архитектуру кода") навыков.
2. Некое принятое полунегласное соглашение о том, как люди на производстве должны общаться друг с другом, нацеленное на воспитание интровертов ("здороваться с коллегами, не ругаться матом, поддерживать разговор о погоде").
3. Общее объяснение/рационализация о том, почему в целом некоторым людям со временем работать надо больше, а денег платят меньше ("у вас просто правильных софт-скиллов нет").
Как не трудно видеть, все три пункта, в целом, могут быть взаимосвязаны, но вообще имеют в качестве стейкхолдера (выгодоприобретателя) разных людей: конкретного индивидуума-специалиста, владельца бизнеса, государство и межгосударственные системы (соответственно пунктам).
Что касается базовых "софт скиллов" для индивидуума, т. е. набора коммуникативно-ментальных навыков, я бы вот какой шорт-лист составил:
1. Раппорт. Простой, традиционно тренируемый, прямолинейный навык установки многоуровневого раппорта даёт +1 балл на экзамене, +10% зарплаты на собеседовании, и в целом прохождение "по верхней границе" всех организационных "вилок" на всех уровнях частных корпоративных/организационных раскладов/интриг и в карьере в целом.
2. Техники формализации через задавание вопросов. Есть куча аббревиатур типа SMART, SWOT, и т. п. Всё это вторичные навороты, а базово нужно умение задавать вопросы к наиболее атомарным элементам высказываний (письменных и устных). Это совершенно непопулярный подход, который является самым нудным и эффективным путём к рефакторингу мышления и получению ряда прикладных навыков (начиная с эффективной формализации технических заданий).
3. Самоуправление мотивацией и принятием решений. Казалось бы, достаточно второстепенная тема, но с тем как мир становится всё сложнее, качественные источники информации всё реже, наличие "внутреннего компаса" для навигации среди всех открывающихся возможностей (или всех встречающихся препятствий и кризисов) постепенно поднимается всё выше в списке приоритетных навыков.
Все стоящие "софт скиллзы" вызывают серьёзные жизненные изменения, которые порождаются серьёзными внутренними (психологическими) изменениями. В то же время, подлинные внутренние изменения не вызывают бурных эмоций, вопреки распространённому мифу и рассуждениям ютюбовских психологинь. Вместе с изменением частных вещей меняется целиком система внутренних оценок, поэтому в новом (изменённом) состоянии и новая внутренняя норма. Т. е. как был человек нормальным, так и остался нормальным, никаких изменений нет. А жизнь поменялась почти целиком.
В этом большой рекламный парадокс: реклама должна давить на простые эмоции, но реклама правильных "софт скиллов" не может этого делать, т. к. вообще про другое.
#psychology #programming
В целом следует отличать три типа софт-скиллов:
1. Личное умение (и набор навыков) для достижения социальных ("быть обеспеченным"), коммуникативных ("добиться повышения зарплаты от начальника") и предметных ("быстро придумывать правильную архитектуру кода") навыков.
2. Некое принятое полунегласное соглашение о том, как люди на производстве должны общаться друг с другом, нацеленное на воспитание интровертов ("здороваться с коллегами, не ругаться матом, поддерживать разговор о погоде").
3. Общее объяснение/рационализация о том, почему в целом некоторым людям со временем работать надо больше, а денег платят меньше ("у вас просто правильных софт-скиллов нет").
Как не трудно видеть, все три пункта, в целом, могут быть взаимосвязаны, но вообще имеют в качестве стейкхолдера (выгодоприобретателя) разных людей: конкретного индивидуума-специалиста, владельца бизнеса, государство и межгосударственные системы (соответственно пунктам).
Что касается базовых "софт скиллов" для индивидуума, т. е. набора коммуникативно-ментальных навыков, я бы вот какой шорт-лист составил:
1. Раппорт. Простой, традиционно тренируемый, прямолинейный навык установки многоуровневого раппорта даёт +1 балл на экзамене, +10% зарплаты на собеседовании, и в целом прохождение "по верхней границе" всех организационных "вилок" на всех уровнях частных корпоративных/организационных раскладов/интриг и в карьере в целом.
2. Техники формализации через задавание вопросов. Есть куча аббревиатур типа SMART, SWOT, и т. п. Всё это вторичные навороты, а базово нужно умение задавать вопросы к наиболее атомарным элементам высказываний (письменных и устных). Это совершенно непопулярный подход, который является самым нудным и эффективным путём к рефакторингу мышления и получению ряда прикладных навыков (начиная с эффективной формализации технических заданий).
3. Самоуправление мотивацией и принятием решений. Казалось бы, достаточно второстепенная тема, но с тем как мир становится всё сложнее, качественные источники информации всё реже, наличие "внутреннего компаса" для навигации среди всех открывающихся возможностей (или всех встречающихся препятствий и кризисов) постепенно поднимается всё выше в списке приоритетных навыков.
Все стоящие "софт скиллзы" вызывают серьёзные жизненные изменения, которые порождаются серьёзными внутренними (психологическими) изменениями. В то же время, подлинные внутренние изменения не вызывают бурных эмоций, вопреки распространённому мифу и рассуждениям ютюбовских психологинь. Вместе с изменением частных вещей меняется целиком система внутренних оценок, поэтому в новом (изменённом) состоянии и новая внутренняя норма. Т. е. как был человек нормальным, так и остался нормальным, никаких изменений нет. А жизнь поменялась почти целиком.
В этом большой рекламный парадокс: реклама должна давить на простые эмоции, но реклама правильных "софт скиллов" не может этого делать, т. к. вообще про другое.
#psychology #programming
К вопросу переселения в нейросети.
Вот, друзья, бытует убеждение, что скоро нейросети дойдут до такого уровня, что человекоподобный искусственный интеллект станет реальностью. А там и можно поставить вопрос переселения разума в облака и здравствуй цифровое бессмертие. Заживём!
Извините, разочарую — не заживём. И дети, и внуки, и правнуки не заживут.
Знакомьтесь – на картинке выше C. elegans, «палкоподобный элегантный», червячок длинной 1мм. Нервную систему червяка формируют 302 нейрона (примечательно, что схема нейросети у него статичная — прошита в геном, в отличие от более развитых-сложных организмов). Создана полная трёхмерная карта связей между этими нейронами (так называемый коннектом). Геном полностью расшифрован.
А дальше начинается ад для нейроучёных, генетиков и биологов, показывающий реальное место всех этих модных и передовых наук в решении гуманистических задач. Ни коннектом, ни геном, не приносят никакой пользы для создания (математической или инженерной) модели, которая бы хотя бы грубо воспроизводила поведение червячка.
Червячок умеет:
1. Ориентироваться в пространстве по гравитационному и магнитному полю.
2. Выслеживать еду (бактерий), применяя механически замысловатые манёвры (за что его и прозвали элегантным).
3. Оценивать температуру среды и передвигаться в сторону оптимальной температуры.
4. Жрать хорошую еду.
5. Не жрать плохую еду.
6. Учиться на своём опыте, запоминая, какая еда хорошая, а какая плохая.
7. Выбирать партнёров для спаривания и размножаться.
На всё про всё 302 нейрона. Попробуйте создайте компьютерную нейросеть, которая воспроизводит аналогичное поведение, на 302 перцептронах.
Живой нейрон C. elegans может напрямую реагировать на окружающую температуру и хранить сам в себе воспоминания (за всю память и восприятие запаха отвечают три нейрона). Более чем сотня нейропептидов (гормонов, нейромедиаторов и иных белков, модулирующих работу нервной системы) вторично влияет на функционирование нервной системы. Нейропептидные связи формируют внутри коннектома что-то вроде подпольной «вторичной» сети обмена информацией.
Учёные не могут сейчас и не смогут в ближайшие 50 (оптимистично – реально, и 100) лет – как показывает опыт применения «атомарного подхода» – переселить в облако жалкую «душонку» этого червячка.
Каждый раз, когда вам на страницах Nature будут хвалиться успехами в моделировании человеческого мозга, спросите мысленно: а чё там с C. elegans-то?
А так, замечательное дело нейросети, могут в шахматы играть, могут в го, ещё при нашей жизни доту освоят, если бюджет не порежут.
#science
Вот, друзья, бытует убеждение, что скоро нейросети дойдут до такого уровня, что человекоподобный искусственный интеллект станет реальностью. А там и можно поставить вопрос переселения разума в облака и здравствуй цифровое бессмертие. Заживём!
Извините, разочарую — не заживём. И дети, и внуки, и правнуки не заживут.
Знакомьтесь – на картинке выше C. elegans, «палкоподобный элегантный», червячок длинной 1мм. Нервную систему червяка формируют 302 нейрона (примечательно, что схема нейросети у него статичная — прошита в геном, в отличие от более развитых-сложных организмов). Создана полная трёхмерная карта связей между этими нейронами (так называемый коннектом). Геном полностью расшифрован.
А дальше начинается ад для нейроучёных, генетиков и биологов, показывающий реальное место всех этих модных и передовых наук в решении гуманистических задач. Ни коннектом, ни геном, не приносят никакой пользы для создания (математической или инженерной) модели, которая бы хотя бы грубо воспроизводила поведение червячка.
Червячок умеет:
1. Ориентироваться в пространстве по гравитационному и магнитному полю.
2. Выслеживать еду (бактерий), применяя механически замысловатые манёвры (за что его и прозвали элегантным).
3. Оценивать температуру среды и передвигаться в сторону оптимальной температуры.
4. Жрать хорошую еду.
5. Не жрать плохую еду.
6. Учиться на своём опыте, запоминая, какая еда хорошая, а какая плохая.
7. Выбирать партнёров для спаривания и размножаться.
На всё про всё 302 нейрона. Попробуйте создайте компьютерную нейросеть, которая воспроизводит аналогичное поведение, на 302 перцептронах.
Живой нейрон C. elegans может напрямую реагировать на окружающую температуру и хранить сам в себе воспоминания (за всю память и восприятие запаха отвечают три нейрона). Более чем сотня нейропептидов (гормонов, нейромедиаторов и иных белков, модулирующих работу нервной системы) вторично влияет на функционирование нервной системы. Нейропептидные связи формируют внутри коннектома что-то вроде подпольной «вторичной» сети обмена информацией.
Учёные не могут сейчас и не смогут в ближайшие 50 (оптимистично – реально, и 100) лет – как показывает опыт применения «атомарного подхода» – переселить в облако жалкую «душонку» этого червячка.
Каждый раз, когда вам на страницах Nature будут хвалиться успехами в моделировании человеческого мозга, спросите мысленно: а чё там с C. elegans-то?
А так, замечательное дело нейросети, могут в шахматы играть, могут в го, ещё при нашей жизни доту освоят, если бюджет не порежут.
#science
К вопросу принципов ОО (объектно-ориентированного) дизайна.
Философские рассуждения строят примерно так. Давайте все согласимся с тем, что "цель жизни — быть счастливым". Затем напишем один том про счастье, другой про цели, третий про жизнь, и четвёртый про бытие.
Принципы ОО-дизайна строят, в свою очередь, так. Давайте согласимся с тем, что "класс должен отвечать за нечто одно". И напишем один том про классы, другой про ответственность, третий для прояснения вопроса что является чем-то одним, а что следует считать двумя разными вещами.
Как не трудно видеть, принципы ОО-дизайна являются видом философских рассуждений, с поправкой на то, что их авторы пытаются, так сказать, сесть не в свои сани: пропускают наработки нескольких веков на тему того, как строить рассуждения на общие темы, чтобы они не превращались в пустопорожнюю болтовню и ментальный эксгибиционизм, и сразу начинают выводить законы функционирования компьютерных систем и человеческого разума.
Натужные попытки проиллюстрировать общие принципы конкретным кодом превращаются, обычно, в иллюстрацию, отрицающую исходный посыл: автор примера сразу же вынужден делать оговорки типа "пример получился дурацкий, и никто так не пишет, но надо же было как-то показать что имеется в виду".
Однако, без каких-то общих принципов тоже сложно обходиться, всякому рациональному человеку хочется поверх практики построить теорию.
Для дизайна простых классов вот к чему стремится всякий разумный программист:
1. Минимизировать "состояние". На практике, это означает использование минимально возможного количества instance-переменных, задающих "базис" объекта. Если у человека в instance-переменных хранится имя и фамилия, то не должно быть instance-переменной, где хранилось бы имя с фамилией одной строкой.
2. Не смешивать "классы-вещи" и "классы-процессы". Если объект "человек" должен, кроме хранения данных об означенном человеке, ещё после своей инициализации сходить на сторонний сервис и отправить пару email-ов, то данный принцип оказался нарушен. Процесс "Регистрация человека" должен быть выделен отдельным классом.
3. Не нарезать код на части без необходимости. Если у некоего метода 200 строк это не повод нарезать его на 20 методов по 10 строк. Поводом станет (реальная или реалистично прогнозируемая) необходимость повторно использовать логику фрагмента этого метода в другом методе.
4. Использовать язык программирования для того, чтобы сделать код понятным другому программисту. Соглашусь, что принцип широкий. Но всё же поддаётся формализации — лингвисты даже естественные языки формализуют вполне успешно. В соответствии с данным принципом:
- название любой сущности (класса, метода, переменной, константы) должно соответствовать содержимому (
- если нечто делается дважды одинаково, то и на третий раз следует делать точно также (следование этому принципу, кроме всего прочего, облегчит рефакторинг повторяющегося кода)
- если нечто можно выразить управляющей конструкцией или оператором языка, не следует изобретать или прятать это внутрь некоего класса или метода
5. Избегать циклических зависимостей (на уровне методов, классов, архитектурных частей проекта).
6. Избегать зависимостей "через слой" — некий архитектурный элемент должен знать только то, что лежит не более одного уровня "выше" или "ниже" (также на уровне методов, классов, архитектурных частей проекта). Снова, на первый взгляд, философский принцип. Но, на самом деле, понятие "архитектурных уровней" вполне неплохо операционализируется — понятно, что "уровень базы данных" на один "ниже", чем "уровень модели" (и в прочих случаях).
7. Снижать "цикломатическую сложность". Например, не вкладывать условие в условие, если можно добавить ветку в корневое условие (аналогично, не вкладывать условие в rescue-блок, проверяя вид исключения, если можно добавить отдельную rescue-ветку; и т. п.).
Вот такие вот семь заповедей разумного программиста :)
#programming
Философские рассуждения строят примерно так. Давайте все согласимся с тем, что "цель жизни — быть счастливым". Затем напишем один том про счастье, другой про цели, третий про жизнь, и четвёртый про бытие.
Принципы ОО-дизайна строят, в свою очередь, так. Давайте согласимся с тем, что "класс должен отвечать за нечто одно". И напишем один том про классы, другой про ответственность, третий для прояснения вопроса что является чем-то одним, а что следует считать двумя разными вещами.
Как не трудно видеть, принципы ОО-дизайна являются видом философских рассуждений, с поправкой на то, что их авторы пытаются, так сказать, сесть не в свои сани: пропускают наработки нескольких веков на тему того, как строить рассуждения на общие темы, чтобы они не превращались в пустопорожнюю болтовню и ментальный эксгибиционизм, и сразу начинают выводить законы функционирования компьютерных систем и человеческого разума.
Натужные попытки проиллюстрировать общие принципы конкретным кодом превращаются, обычно, в иллюстрацию, отрицающую исходный посыл: автор примера сразу же вынужден делать оговорки типа "пример получился дурацкий, и никто так не пишет, но надо же было как-то показать что имеется в виду".
Однако, без каких-то общих принципов тоже сложно обходиться, всякому рациональному человеку хочется поверх практики построить теорию.
Для дизайна простых классов вот к чему стремится всякий разумный программист:
1. Минимизировать "состояние". На практике, это означает использование минимально возможного количества instance-переменных, задающих "базис" объекта. Если у человека в instance-переменных хранится имя и фамилия, то не должно быть instance-переменной, где хранилось бы имя с фамилией одной строкой.
2. Не смешивать "классы-вещи" и "классы-процессы". Если объект "человек" должен, кроме хранения данных об означенном человеке, ещё после своей инициализации сходить на сторонний сервис и отправить пару email-ов, то данный принцип оказался нарушен. Процесс "Регистрация человека" должен быть выделен отдельным классом.
3. Не нарезать код на части без необходимости. Если у некоего метода 200 строк это не повод нарезать его на 20 методов по 10 строк. Поводом станет (реальная или реалистично прогнозируемая) необходимость повторно использовать логику фрагмента этого метода в другом методе.
4. Использовать язык программирования для того, чтобы сделать код понятным другому программисту. Соглашусь, что принцип широкий. Но всё же поддаётся формализации — лингвисты даже естественные языки формализуют вполне успешно. В соответствии с данным принципом:
- название любой сущности (класса, метода, переменной, константы) должно соответствовать содержимому (
array плохо, apples хорошо и др.)- если нечто делается дважды одинаково, то и на третий раз следует делать точно также (следование этому принципу, кроме всего прочего, облегчит рефакторинг повторяющегося кода)
- если нечто можно выразить управляющей конструкцией или оператором языка, не следует изобретать или прятать это внутрь некоего класса или метода
5. Избегать циклических зависимостей (на уровне методов, классов, архитектурных частей проекта).
6. Избегать зависимостей "через слой" — некий архитектурный элемент должен знать только то, что лежит не более одного уровня "выше" или "ниже" (также на уровне методов, классов, архитектурных частей проекта). Снова, на первый взгляд, философский принцип. Но, на самом деле, понятие "архитектурных уровней" вполне неплохо операционализируется — понятно, что "уровень базы данных" на один "ниже", чем "уровень модели" (и в прочих случаях).
7. Снижать "цикломатическую сложность". Например, не вкладывать условие в условие, если можно добавить ветку в корневое условие (аналогично, не вкладывать условие в rescue-блок, проверяя вид исключения, если можно добавить отдельную rescue-ветку; и т. п.).
Вот такие вот семь заповедей разумного программиста :)
#programming
Три стадии развития продуктивности и преодоления прокрастинации:
1. Делаешь вид, что всё время с момента предыдущего обращения чем-то занимался, героически преодолевая возникшие серьёзные затруднения, чтобы не смущать коллег своим существенным отставанием от общего темпа работы.
2. Нормально работаешь наравне со всеми.
3. Делаешь вид, что всё время с момента предыдущего обращения чем-то занимался, героически преодолевая возникшие серьёзные затруднения, чтобы не смущать коллег своим существенным опережением общего темпа работы.
1. Делаешь вид, что всё время с момента предыдущего обращения чем-то занимался, героически преодолевая возникшие серьёзные затруднения, чтобы не смущать коллег своим существенным отставанием от общего темпа работы.
2. Нормально работаешь наравне со всеми.
3. Делаешь вид, что всё время с момента предыдущего обращения чем-то занимался, героически преодолевая возникшие серьёзные затруднения, чтобы не смущать коллег своим существенным опережением общего темпа работы.
К вопросу оригинальных изобретений, разработок и открытий
Считается, что вся современная социальная активность людей построена вокруг коллективной деятельности и труда. На самом деле, если присмотреться, никаких коллективов не существует. Есть отдельные творческие личности, которые в некоторый момент времени придумывают нечто оригинальное. Некоторых таких личностей социум начинает пиарить из каждого утюга (иногда вполне заслужено). Роль других затеняется и не афишируется.
Но в центре открытия всегда один конкретный человек. По-другому не бывает.
В программировании мы знаем фон Неймана, Тьюринга, Дейкстру, Вирта, и т. д. и т. п. Их деятельность как раз, можно так сказать, выставляется напоказ, и они получают свою долю славы. Столпы.
Но скольких мы не знаем? Вот, например, Андерс Хейлсберг. Легендарная личность. Разработал Turbo Pascal (1983), который стал одним из опорных продуктов компании Borland. Затем, во главе собственной команды под крылом того же Borland, разработал Delphi (1986-1996).
А потом компания Borland, очевидно, решила поспорить с мыслью, вынесенной в первый параграф данной заметки. Что нет незаменимых людей и вливание достаточного количества денег в коллектив хорошо обученных сотрудников автоматически приведёт к получению творческих результатов, даже если изъять некую центральную личность.
И Хейлсберг переходит в Microsoft (1996), где разрабатывает язык C# (2000), перенося, кроме прочего, в некоем трансформированном виде все наработки "быстрого прототипирования и разработки оконных приложений", которые были им заложены в Delphi.
Borland и Delphi по инерции плюхаются ещё чуть ли не 10 лет, но воду из бассейна уже слили. Видимость жизни можно поддерживать даже в трупе, "были бы бабки", но всё же это не жизнь.
Ну а C# сейчас используется в каждом утюге, от веб-приложений до мобильных игр.
Хейлсберг сейчас (с 2012) занимается разработкой TypeScript под крылом Microsoft.
Google, напротив, по-видимому, исповедует корпоративную политику "никогда не давать инженерам власти". Для разработки Dart привлекают ДВУХ программистов – Dart разрабатывает "коллектив полуанонимных разработчиков" вместо конкретного (в определённой мере) выдающегося главного конструктора.
Итог закономерен: TypeScript это новый мейнстрим и конвенциональный инструмент во фронтенде (во фронтенде! где на каждый чих десять уникальных трендовых альтернатив), а Dart это очередная поделка для кладбища неудавшихся проектов.
Любой реальный инженерный и научный продукт всегда может быть атрибутирован конкретной личности, которая сыграла центральную роль в его разработке. "Коллектив авторов" – это bullshit, который указывает на то, что под видом научного или инженерного продукта пытаются впарить продукт политический или теологический. Для Библии "коллектив авторов" – почему бы и нет? Для физического принципа, компьютерной технологии, психологической практики — нет, ребята, так не бывает.
#science #programming
Считается, что вся современная социальная активность людей построена вокруг коллективной деятельности и труда. На самом деле, если присмотреться, никаких коллективов не существует. Есть отдельные творческие личности, которые в некоторый момент времени придумывают нечто оригинальное. Некоторых таких личностей социум начинает пиарить из каждого утюга (иногда вполне заслужено). Роль других затеняется и не афишируется.
Но в центре открытия всегда один конкретный человек. По-другому не бывает.
В программировании мы знаем фон Неймана, Тьюринга, Дейкстру, Вирта, и т. д. и т. п. Их деятельность как раз, можно так сказать, выставляется напоказ, и они получают свою долю славы. Столпы.
Но скольких мы не знаем? Вот, например, Андерс Хейлсберг. Легендарная личность. Разработал Turbo Pascal (1983), который стал одним из опорных продуктов компании Borland. Затем, во главе собственной команды под крылом того же Borland, разработал Delphi (1986-1996).
А потом компания Borland, очевидно, решила поспорить с мыслью, вынесенной в первый параграф данной заметки. Что нет незаменимых людей и вливание достаточного количества денег в коллектив хорошо обученных сотрудников автоматически приведёт к получению творческих результатов, даже если изъять некую центральную личность.
И Хейлсберг переходит в Microsoft (1996), где разрабатывает язык C# (2000), перенося, кроме прочего, в некоем трансформированном виде все наработки "быстрого прототипирования и разработки оконных приложений", которые были им заложены в Delphi.
Borland и Delphi по инерции плюхаются ещё чуть ли не 10 лет, но воду из бассейна уже слили. Видимость жизни можно поддерживать даже в трупе, "были бы бабки", но всё же это не жизнь.
Ну а C# сейчас используется в каждом утюге, от веб-приложений до мобильных игр.
Хейлсберг сейчас (с 2012) занимается разработкой TypeScript под крылом Microsoft.
Google, напротив, по-видимому, исповедует корпоративную политику "никогда не давать инженерам власти". Для разработки Dart привлекают ДВУХ программистов – Dart разрабатывает "коллектив полуанонимных разработчиков" вместо конкретного (в определённой мере) выдающегося главного конструктора.
Итог закономерен: TypeScript это новый мейнстрим и конвенциональный инструмент во фронтенде (во фронтенде! где на каждый чих десять уникальных трендовых альтернатив), а Dart это очередная поделка для кладбища неудавшихся проектов.
Любой реальный инженерный и научный продукт всегда может быть атрибутирован конкретной личности, которая сыграла центральную роль в его разработке. "Коллектив авторов" – это bullshit, который указывает на то, что под видом научного или инженерного продукта пытаются впарить продукт политический или теологический. Для Библии "коллектив авторов" – почему бы и нет? Для физического принципа, компьютерной технологии, психологической практики — нет, ребята, так не бывает.
#science #programming
К вопросу преподавания.
Вполне в духе современных трендов будет сказать, что ученик (студент – тем более, если это взрослый человек) — это некая сферическая вещь в себе. Хороший ученик сам всему научится. А плохой ученик никогда ничему не научится, как не старайся его научить. Можно подвести слона к водопою, но нельзя заставить его пить, и всё такое.
Данная позиция может быть приемлема для какого-нибудь современного философа широких взглядов, однако для преподавателя является грубой ошибкой.
Преподавание пересекается с воспитанием и, в современных реалиях, с более общими формами "помогающей деятельности". В чём отличие "тьюторинга" от "коучинга"? Вот вы смеётесь, а это, на самом деле, интересный и актуальный вопрос :)
Всю суть преподавания можно сформулировать в виде программы из двух пунктов:
– деятельно формировать собственные ожидания того, что ученик достигнет поставленных учебных целей, и передавать эти ожидания ученику и (возможно, опосредовано) его релевантному окружению
– проводить процесс интериоризации учебных материалов
Задача методиста, в отличие от преподавателя, заключается в подготовке (или подборе) учебных материалов и конкретных технических средств реализации обоих пунктов данной программы. Иногда роли совмещаются.
Можно сказать, что коуч — это преподаватель в особенной области ментальных и поведенческих навыков. Т.е. он, грубо говоря, учит эффективному мышлению (коммуникации, социальным навыкам, и, по современной моде, чему угодно ещё похожему).
Психологический консультант — первый пункт (формирование ожиданий) сохраняется, а вот интериоризацией неких полезных мыслительных процессов он может заниматься вообще без наглядного материала.
Ну, может показаться, что вышли абстрактные определения, но, на самом деле, вполне практически применимые. К примеру вот какие оценки можно с их помощью давать в отношении преподавателя:
1. Если преподаватель ведёт устное повествование без наглядных материалов, то это, по определению, не преподавание. Может быть это проповедь, может быть психологическая лекция, может ещё что такое.
2. Если преподаватель высказывает безальтернативные негативные прогнозы в отношении ученика, то он не выполняет свою профессиональную обязанность — поддержание конструктивных ожиданий. Следует заметить, что необходимость поддержания таких ожиданий вытекает не из каких-то этических соображений, а из прямой технической необходимости (см. эффект Пигмалиона-Розенталя и бесчисленную базу экспериментов, связанную с ним).
3. Если преподаватель употребляет ораторское мастерство в том месте, где можно применить наглядный материал (вместо того, чтобы показать страницу учебника со схемой начинает рассуждать о необходимости прилагать больше усилий и т. п.), то он занимается продажей не той услуги, которую клиент оплатил. Может быть это и хорошая услуга, но это не преподавание.
Важно отметить, что преподавание (как и деятельность всех иных "человеко-ориентированных" профессий) начинается с момента заключения договора (что может быть сделано в достаточно не формальной, лаконичной, но всё же отчётливо осознаваемой обеими сторонами форме).
Я писал ранее, что мотивирует программиста.
Преподавателя мотивируют:
– оплата услуг (как и в любой другой профессии)
– применение хорошо подготовленных (методистами; или им самим в роли методиста) материалов ("техническая" мотивация)
– подготовка студентов, которые деятельно демонстрируют решительность дойти до конца ("гуманистическая" мотивация)
Напрашивается простой вывод: если хотите попытаться напроситься к профессиональному преподавателю в ученики за бесплатно или со скидкой, то попросите его научить тем темам, на которые у него есть хороший "материальчик", и сделайте вид, что решительно намерены дойти в своём обучении до конца (даже если сами сомневаетесь) :)
#education
Вполне в духе современных трендов будет сказать, что ученик (студент – тем более, если это взрослый человек) — это некая сферическая вещь в себе. Хороший ученик сам всему научится. А плохой ученик никогда ничему не научится, как не старайся его научить. Можно подвести слона к водопою, но нельзя заставить его пить, и всё такое.
Данная позиция может быть приемлема для какого-нибудь современного философа широких взглядов, однако для преподавателя является грубой ошибкой.
Преподавание пересекается с воспитанием и, в современных реалиях, с более общими формами "помогающей деятельности". В чём отличие "тьюторинга" от "коучинга"? Вот вы смеётесь, а это, на самом деле, интересный и актуальный вопрос :)
Всю суть преподавания можно сформулировать в виде программы из двух пунктов:
– деятельно формировать собственные ожидания того, что ученик достигнет поставленных учебных целей, и передавать эти ожидания ученику и (возможно, опосредовано) его релевантному окружению
– проводить процесс интериоризации учебных материалов
Задача методиста, в отличие от преподавателя, заключается в подготовке (или подборе) учебных материалов и конкретных технических средств реализации обоих пунктов данной программы. Иногда роли совмещаются.
Можно сказать, что коуч — это преподаватель в особенной области ментальных и поведенческих навыков. Т.е. он, грубо говоря, учит эффективному мышлению (коммуникации, социальным навыкам, и, по современной моде, чему угодно ещё похожему).
Психологический консультант — первый пункт (формирование ожиданий) сохраняется, а вот интериоризацией неких полезных мыслительных процессов он может заниматься вообще без наглядного материала.
Ну, может показаться, что вышли абстрактные определения, но, на самом деле, вполне практически применимые. К примеру вот какие оценки можно с их помощью давать в отношении преподавателя:
1. Если преподаватель ведёт устное повествование без наглядных материалов, то это, по определению, не преподавание. Может быть это проповедь, может быть психологическая лекция, может ещё что такое.
2. Если преподаватель высказывает безальтернативные негативные прогнозы в отношении ученика, то он не выполняет свою профессиональную обязанность — поддержание конструктивных ожиданий. Следует заметить, что необходимость поддержания таких ожиданий вытекает не из каких-то этических соображений, а из прямой технической необходимости (см. эффект Пигмалиона-Розенталя и бесчисленную базу экспериментов, связанную с ним).
3. Если преподаватель употребляет ораторское мастерство в том месте, где можно применить наглядный материал (вместо того, чтобы показать страницу учебника со схемой начинает рассуждать о необходимости прилагать больше усилий и т. п.), то он занимается продажей не той услуги, которую клиент оплатил. Может быть это и хорошая услуга, но это не преподавание.
Важно отметить, что преподавание (как и деятельность всех иных "человеко-ориентированных" профессий) начинается с момента заключения договора (что может быть сделано в достаточно не формальной, лаконичной, но всё же отчётливо осознаваемой обеими сторонами форме).
Я писал ранее, что мотивирует программиста.
Преподавателя мотивируют:
– оплата услуг (как и в любой другой профессии)
– применение хорошо подготовленных (методистами; или им самим в роли методиста) материалов ("техническая" мотивация)
– подготовка студентов, которые деятельно демонстрируют решительность дойти до конца ("гуманистическая" мотивация)
Напрашивается простой вывод: если хотите попытаться напроситься к профессиональному преподавателю в ученики за бесплатно или со скидкой, то попросите его научить тем темам, на которые у него есть хороший "материальчик", и сделайте вид, что решительно намерены дойти в своём обучении до конца (даже если сами сомневаетесь) :)
#education
Telegram
Metaprogramming
Почему НЕ надо становиться программистом. Из каждого утюга пишут про то, как классно быть программистом (автор - конечно, один из таких "утюгов"), для разнообразия напишем, почему (новичку) не надо становиться программистом:
1. Недостаток программистов …
1. Недостаток программистов …
О национальном характере (пост к выходным)
На днях наблюдал забавное отличие русского (или российского) менталитета от западно-европейского. В некоторой сессионной игре параллельно представители двух национальностей вели свободный диалог с постоянными товарищами по команде (возраст участников примерно одинаковый – студенты-старшекурсники).
Диалог западно-европейских игроков примерно такой:
— День добрый, как вчера сыграли?
— Привет, ещё одну партию выиграли и спать разошлись. Карта была не очень интересной.
— Нормально, мы тут тоже на днях её пройти хотим. Ну чего, погнали партейку?
— Давай.
Диалог русских:
— Здорово, чего делаешь?
— Привет, музыку слушаю.
— Слушай, а какая тебе музыка нравится?
— Музыка, ну разная музыка нравится. И такая музыка нравится, и сякая, и всякая. И вообще, можно ли сказать, что музыка определяет человека? А зачем ты спрашиваешь? Вот отвечу я тебе нечто, но разве можно обо мне будет сказать по этому поводу что-то? Да и всё равно ты этих групп не знаешь. Да я вообще соврать могу, ты же не проверишь это никак. У человека в целом много интересов может быть, и музыка это лишь небольшая часть этой сферы увлечений. Я, кстати, этим аккаунтом не часто пользуюсь, обычно под другим сижу. Вчера под ним проходили карту одну, так до конца не дошли. Да и зачем вообще доходить до конца? Мы же ради удовольствия играем. Дошли, не дошли, какая разница, что мне эти циферки в рейтинге, я их на хлеб что ли намазывать буду? Секунду, в дискорде пишет кто-то, сейчас вернусь.
Это было настолько поразительным примером для меня (клянусь, я лишь немного его огранил для художественного изложения), но, с другой стороны, парадоксально открыло глаза на тот удивительный факт, что в России, не смотря на столетнее (по сути религиозное) иго в отношении всех гуманитарных наук, существует и в определённой степени продуктивно учение "методологии психологии" (к которому, если брать в широком смысле, и я имею некоторое отношение). На Западе есть лишь "методы исследования" – research methods (то есть набор типовых рецептов раскладки экспериментальных групп и последующего статистического анализа результатов).
Если русские студенты такие тексты порождают на ровном месте, то не удивительно, что в научной среде рождается такое:
#psychology
На днях наблюдал забавное отличие русского (или российского) менталитета от западно-европейского. В некоторой сессионной игре параллельно представители двух национальностей вели свободный диалог с постоянными товарищами по команде (возраст участников примерно одинаковый – студенты-старшекурсники).
Диалог западно-европейских игроков примерно такой:
— День добрый, как вчера сыграли?
— Привет, ещё одну партию выиграли и спать разошлись. Карта была не очень интересной.
— Нормально, мы тут тоже на днях её пройти хотим. Ну чего, погнали партейку?
— Давай.
Диалог русских:
— Здорово, чего делаешь?
— Привет, музыку слушаю.
— Слушай, а какая тебе музыка нравится?
— Музыка, ну разная музыка нравится. И такая музыка нравится, и сякая, и всякая. И вообще, можно ли сказать, что музыка определяет человека? А зачем ты спрашиваешь? Вот отвечу я тебе нечто, но разве можно обо мне будет сказать по этому поводу что-то? Да и всё равно ты этих групп не знаешь. Да я вообще соврать могу, ты же не проверишь это никак. У человека в целом много интересов может быть, и музыка это лишь небольшая часть этой сферы увлечений. Я, кстати, этим аккаунтом не часто пользуюсь, обычно под другим сижу. Вчера под ним проходили карту одну, так до конца не дошли. Да и зачем вообще доходить до конца? Мы же ради удовольствия играем. Дошли, не дошли, какая разница, что мне эти циферки в рейтинге, я их на хлеб что ли намазывать буду? Секунду, в дискорде пишет кто-то, сейчас вернусь.
Это было настолько поразительным примером для меня (клянусь, я лишь немного его огранил для художественного изложения), но, с другой стороны, парадоксально открыло глаза на тот удивительный факт, что в России, не смотря на столетнее (по сути религиозное) иго в отношении всех гуманитарных наук, существует и в определённой степени продуктивно учение "методологии психологии" (к которому, если брать в широком смысле, и я имею некоторое отношение). На Западе есть лишь "методы исследования" – research methods (то есть набор типовых рецептов раскладки экспериментальных групп и последующего статистического анализа результатов).
Если русские студенты такие тексты порождают на ровном месте, то не удивительно, что в научной среде рождается такое:
Психологическая регуляция принятия решений, или выборов человека в условиях неопределенности, включает на сегодняшний день ряд дихотомий: разведение понятий «принятие решений как выбор» и «выбор как деятельность», рациональный и личностный выбор, ситуационные и диспозициональные условия субъективной неопределенности и ряд других. Выделение разных предметов исследования при изучении выбора и интерпретационные предпочтения позволяют авторам настаивать на том, что преимущественно выбор определяется когнитивными структурами или личностными. Выходом из сложившегося положения дел, задаваемого соотношением концепций в рамках познавательного, мотивационного и праксиологического подходов, является переход к динамической парадигме в психологических исследованиях, предполагающей поиск не структур, а динамически складывающихся иерархий регулятивных процессов.И, конечно, данную черту и порождаемое ей творчество можно оценивать по-разному, но в целом хорошо, что подобная оппозиция традиционному западному редукционизму существует.
#psychology
"Невезучий год"
В большей или меньшей мере, но все люди обращают внимание на ощущение "везения" или "невезения". Кто-то всерьёз считает свою везучесть или невезучесть важным личным свойством, кто-то отмечает лишь мимоходом; кто-то списывает на случайность, кто-то всерьёз заранее готовится.
Но этот год примечателен тем, что всему человечеству "не повезло". Примечательно здесь то, что, в противовес конкретным материальным потерям, которые перенесла пусть значительная, но всё же часть человечества, это иррациональное ощущение "невезения" воздействует на всех – даже на тех, кто объективно не проиграл (а может и немного выиграл) в сложившихся обстоятельствах.
Что, конечно, является иллюстрацией феномена "коллективности" человеческого сознания. Душа болит за человечество! :)
#psychology
В большей или меньшей мере, но все люди обращают внимание на ощущение "везения" или "невезения". Кто-то всерьёз считает свою везучесть или невезучесть важным личным свойством, кто-то отмечает лишь мимоходом; кто-то списывает на случайность, кто-то всерьёз заранее готовится.
Но этот год примечателен тем, что всему человечеству "не повезло". Примечательно здесь то, что, в противовес конкретным материальным потерям, которые перенесла пусть значительная, но всё же часть человечества, это иррациональное ощущение "невезения" воздействует на всех – даже на тех, кто объективно не проиграл (а может и немного выиграл) в сложившихся обстоятельствах.
Что, конечно, является иллюстрацией феномена "коллективности" человеческого сознания. Душа болит за человечество! :)
#psychology
Рецепт успешного миллиардного бизнеса
Как сделать бизнес, который очень быстро захватит национальный (а следом и международный) рынок? Рецепт очень простой и хорошо воспроизводимый.
Допустим, мы хотим стать самым популярным производителем шаурмы. Для этого нам надо, всего лишь, не брать 150 рублей с клиентов, а доплачивать каждому, для начала, 50 рублей. Если появится конкурент с похожей бизнес-моделью, то стоит начать доплачивать 100 рублей.
Стоит отметить, что, при каждущейся абсурдности, подобной бизнес-модели следует уже который год Uber, AirBnB, Tesla, и т. д.
В целом можно рассматривать такой расклад с двух точек зрения, при которых подобная стратегия обретает смысл:
1. Раздаются не свои деньги. Конкретно, раздаются деньги инвесторов, привлечённых в момент очередной эмиссии акций, которые привлекаются под обещания дальнейшего роста стоимости акций, за счёт привлечения новых инвесторов, и т. п.
2. Владельцы организации получают выгоду не от этой организации (то есть рассматриваемая организация, по сути, является некоммерческой – кстати, иногда декларация "нам деньги не нужны" прямо в таком виде звучит из уст мажоритарного акционера или высшего руководства компании). Например, владельцы считают убытки терпимыми на фоне получаемого доступа к персональной информации и т. п.
Здесь хотел отметить, что покупку акций подобных компаний не стоит для самого себя обозначать словами "инвестиции" или "вложение в бизнес", или ещё чем-то вроде того. Бизнеса (то есть прибыльного дела) потому что в такой схеме нет (точнее будет сказать, он есть, но не соответствует формально обозначаемой деятельности). На таких акциях можно "заработать", но нельзя "зарабатывать на пенсию".
Впрочем, как всегда, это не инвестиционная рекомендация, а автор не является профессиональным инвестором.
#investing
Как сделать бизнес, который очень быстро захватит национальный (а следом и международный) рынок? Рецепт очень простой и хорошо воспроизводимый.
Допустим, мы хотим стать самым популярным производителем шаурмы. Для этого нам надо, всего лишь, не брать 150 рублей с клиентов, а доплачивать каждому, для начала, 50 рублей. Если появится конкурент с похожей бизнес-моделью, то стоит начать доплачивать 100 рублей.
Стоит отметить, что, при каждущейся абсурдности, подобной бизнес-модели следует уже который год Uber, AirBnB, Tesla, и т. д.
В целом можно рассматривать такой расклад с двух точек зрения, при которых подобная стратегия обретает смысл:
1. Раздаются не свои деньги. Конкретно, раздаются деньги инвесторов, привлечённых в момент очередной эмиссии акций, которые привлекаются под обещания дальнейшего роста стоимости акций, за счёт привлечения новых инвесторов, и т. п.
2. Владельцы организации получают выгоду не от этой организации (то есть рассматриваемая организация, по сути, является некоммерческой – кстати, иногда декларация "нам деньги не нужны" прямо в таком виде звучит из уст мажоритарного акционера или высшего руководства компании). Например, владельцы считают убытки терпимыми на фоне получаемого доступа к персональной информации и т. п.
Здесь хотел отметить, что покупку акций подобных компаний не стоит для самого себя обозначать словами "инвестиции" или "вложение в бизнес", или ещё чем-то вроде того. Бизнеса (то есть прибыльного дела) потому что в такой схеме нет (точнее будет сказать, он есть, но не соответствует формально обозначаемой деятельности). На таких акциях можно "заработать", но нельзя "зарабатывать на пенсию".
Впрочем, как всегда, это не инвестиционная рекомендация, а автор не является профессиональным инвестором.
#investing
Поздравляю с Новым годом!
Моё открытие года в том, что python ничем не отличается от ruby. Казалось бы, хоть какие-то минимальные отличия должны быть, но по факту вообще никаких.
Конечно, кроме того факта, что ruby в большей мере соответствует знаменитому дзену python.
#programming
Моё открытие года в том, что python ничем не отличается от ruby. Казалось бы, хоть какие-то минимальные отличия должны быть, но по факту вообще никаких.
Конечно, кроме того факта, что ruby в большей мере соответствует знаменитому дзену python.
#programming
Хроники смерти Ruby: первоисточник (1/6)
Сейчас можно считать сложившимся мнением среди настоящих софтверных инженеров, привыкших получать информацию из третьих рук и доверять экспертному мнению профессиональных IT-журналистов, что Ruby умирает (вариант: уже умер).
Интересно проследить историческую перспективу развития вопроса.
Впервые поднял тему, взявши сразу быка за рога, некий Jeff Cogswell в статье от 2014 года с недвусмысленным названием "5 языков программирования, назначенных умереть" ("5 Programming Languages Marked for Death").
Раздел про Ruby начинается с предложения, пытающегося подчеркнуть для читателей, насколько автор в теме: "всего десять лет назад, Руби был на пике моды [по Руби все сходили с ума]". Напомню, десять лет назад от момента написания статьи был 2004 год. Два года до выхода первой версии Ruby on Rails. Ruby вообще никто не знал, это был хоббийный проект нескольких неизвестных японских разработчиков из академических кругов.
Но всё же за что Джефф приговорил Ruby?
Утверждает, что, мол, "мы, люди, которые выросли на С-подобном синтаксисе, путаемся и спотыкаемся при изучении того, как работает Ruby". Дальше приводит два примера, в чём профессиональные С-программисты путаются: "hello, world" и функция для вычисления факториала:
Дальше в статье приводится типовой аргумент "про Твиттер": "все любят язык, а вот Твиттер переписал весь проект с Ruby, т.к. не хватило производительности".
Для динамического языка, вообще говоря, нет ничего позорного в эволюции проекта вида "быстро написали, потом переписали на статическом языке". Это нормальное и даже целевое применение технологии. Благодаря этому Твиттер смог получить первых пользователей и, не застряв в болоте Java-разработки, заработать денег на дальнейшее развитие. Закономерный ход типовой эволюции стартапа. Но примечательно здесь то, что второго примера, кроме Твиттера, такой эволюции для Ruby никогда не приводят. Проектов на Rails сколько угодно любых размеров, а вот примеров отказа от технологии единицы. То есть в плане производительности Ruby/Rails всех, по большому счёту, устраивает.
Итак, Джефф пишет, с лёгкой иронией и играя словами, что в 2011 году Ruby уже, в мыслях автора, умер. В тот же год в реальном мире разработчик языка, Юкихиро Матсумото, был принят на руководящую техническую позицию в Heroku, недавно закрывшего сделку по продаже компании (2010) за $200 млн.
Heroku начал свой путь как система развёртывания и хостинга Ruby-приложений. Так сказать, от Ruby-разработчиков для Ruby-разработчиков. И так лихо сделал и реализовал ставку на умирающий язык, что за три года из "гаражного стартапа" превратился в одного из лидеров начавшейся индустрии "контейнерных-облачных хостингов".
В то время крупнейшие компании практически одновременно начали "гонку вооружений" за раздел только начавшего появляться (но уже заранее понятно, что сулящего огромные прибыли) рынка "цифровых облаков". Amazon запускает AWS (2006); Google – Cloud Platform (2008); Microsoft, спохватившись позднее всех, Azure (2010). В разгар битвы слона, кита и бегемота без лишнего шума и пыли откусывает значительную часть пирога Heroku (2007-2010), который практически сразу выкупает разработчик CRM-систем Salesforce (2010). Актив не совсем профильный, но Salesforce верно рассчитала, что дело того стоит, да и цена сделки, в масштабе разворачивающихся событий, копеечная. Благодаря своей прозорливости Salesforce до сих пор борется с "облачными конкурентами" более чем на равных. Heroku остаётся обособленным подразделением, продолжающим развивать платформу под крылом материнской компании.
#programming #ruby
Сейчас можно считать сложившимся мнением среди настоящих софтверных инженеров, привыкших получать информацию из третьих рук и доверять экспертному мнению профессиональных IT-журналистов, что Ruby умирает (вариант: уже умер).
Интересно проследить историческую перспективу развития вопроса.
Впервые поднял тему, взявши сразу быка за рога, некий Jeff Cogswell в статье от 2014 года с недвусмысленным названием "5 языков программирования, назначенных умереть" ("5 Programming Languages Marked for Death").
Раздел про Ruby начинается с предложения, пытающегося подчеркнуть для читателей, насколько автор в теме: "всего десять лет назад, Руби был на пике моды [по Руби все сходили с ума]". Напомню, десять лет назад от момента написания статьи был 2004 год. Два года до выхода первой версии Ruby on Rails. Ruby вообще никто не знал, это был хоббийный проект нескольких неизвестных японских разработчиков из академических кругов.
Но всё же за что Джефф приговорил Ruby?
Утверждает, что, мол, "мы, люди, которые выросли на С-подобном синтаксисе, путаемся и спотыкаемся при изучении того, как работает Ruby". Дальше приводит два примера, в чём профессиональные С-программисты путаются: "hello, world" и функция для вычисления факториала:
puts 'Bye bye, Miss American Ruby! Drove my Chevy to the Levie…'Текст примеров понятен даже человеку, который вообще не умеет программировать.
puts '2011 was the day that Ruby died, yeah…'
def fact(n)
if n == 0
1
else
n * fact(n-1)
end
end
puts fact(ARGV[0].to_i)
Дальше в статье приводится типовой аргумент "про Твиттер": "все любят язык, а вот Твиттер переписал весь проект с Ruby, т.к. не хватило производительности".
Для динамического языка, вообще говоря, нет ничего позорного в эволюции проекта вида "быстро написали, потом переписали на статическом языке". Это нормальное и даже целевое применение технологии. Благодаря этому Твиттер смог получить первых пользователей и, не застряв в болоте Java-разработки, заработать денег на дальнейшее развитие. Закономерный ход типовой эволюции стартапа. Но примечательно здесь то, что второго примера, кроме Твиттера, такой эволюции для Ruby никогда не приводят. Проектов на Rails сколько угодно любых размеров, а вот примеров отказа от технологии единицы. То есть в плане производительности Ruby/Rails всех, по большому счёту, устраивает.
Итак, Джефф пишет, с лёгкой иронией и играя словами, что в 2011 году Ruby уже, в мыслях автора, умер. В тот же год в реальном мире разработчик языка, Юкихиро Матсумото, был принят на руководящую техническую позицию в Heroku, недавно закрывшего сделку по продаже компании (2010) за $200 млн.
Heroku начал свой путь как система развёртывания и хостинга Ruby-приложений. Так сказать, от Ruby-разработчиков для Ruby-разработчиков. И так лихо сделал и реализовал ставку на умирающий язык, что за три года из "гаражного стартапа" превратился в одного из лидеров начавшейся индустрии "контейнерных-облачных хостингов".
В то время крупнейшие компании практически одновременно начали "гонку вооружений" за раздел только начавшего появляться (но уже заранее понятно, что сулящего огромные прибыли) рынка "цифровых облаков". Amazon запускает AWS (2006); Google – Cloud Platform (2008); Microsoft, спохватившись позднее всех, Azure (2010). В разгар битвы слона, кита и бегемота без лишнего шума и пыли откусывает значительную часть пирога Heroku (2007-2010), который практически сразу выкупает разработчик CRM-систем Salesforce (2010). Актив не совсем профильный, но Salesforce верно рассчитала, что дело того стоит, да и цена сделки, в масштабе разворачивающихся событий, копеечная. Благодаря своей прозорливости Salesforce до сих пор борется с "облачными конкурентами" более чем на равных. Heroku остаётся обособленным подразделением, продолжающим развивать платформу под крылом материнской компании.
#programming #ruby
Ну а Джефф к моменту написания статьи уже сильно отошёл от программирования ("разработку на jQuery" за программирование считать не будем). Зато всерьёз занялся набравшим популярность devops-ом. На наборе технологий прямого конкурента Heroku – AWS. Через год после написания статьи его собственный бизнес на данную хайповую тему "не пошёл" и был "приостановлен на неопределённое время", но, к счастью, ниша для "консультанта по облакам" с опытом С++ и без понимания потребностей стартапов находится. Джефф в конечном итоге оседает "AWS-консультантом" в крошечном провинциальном провайдере услуг телефонии и интернета. Что ж, дело полезное: как минимум, кто-то должен объяснять, в чём именно польза от освоения средств на "облачную инфраструктуру" (для телефонной компании).
Инженер, списавший Ruby в устаревшие языки, был списан как устаревший программист и бизнесмен. Диалектика.
#programming #ruby
Инженер, списавший Ruby в устаревшие языки, был списан как устаревший программист и бизнесмен. Диалектика.
#programming #ruby
Хроники смерти Ruby: круги на воде (2/6)
Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.
"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.
В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.
Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".
Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".
Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.
Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).
Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).
#programming #ruby
Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.
"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.
В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.
Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".
Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".
Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.
Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).
Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).
#programming #ruby
Хроники смерти Ruby: старички на марше (3/6)
Переходим к 2016-2017 годам.
Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.
Ну, во-первых, используется ещё в Devops.
Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.
По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".
Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:
2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"
К пляскам присоединились самые широкие массы трудящихся.
Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).
В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.
Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.
К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.
Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.
#programming #ruby
Переходим к 2016-2017 годам.
Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.
Ну, во-первых, используется ещё в Devops.
Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.
По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".
Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:
2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"
К пляскам присоединились самые широкие массы трудящихся.
Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).
В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.
Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.
К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.
Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.
#programming #ruby
Хроники смерти Ruby: Ruby и Elixir (4/6)
Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.
Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.
Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.
#programming #ruby
Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.
Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.
Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.
#programming #ruby