Хорошо, что лично Вам не помешает.
С Erlang/OTP всё-таки есть прямая связь: Elixir код выполняется на виртуальной машине Erlang, половина его stdlib — обертки над stdlib Erlang, любое приложение на Elixir использует OTP, а Phoenix так вообще очень плотно на OTP опирается.
Что касается Ruby, то связь только такая: на обоих языках приятно программировать и автор Elixir имеет богатый опыт программирования на Ruby. Всё, на этом полезные параллели между Elixir и Ruby заканчиваются.
Во-первых, далеко не любая… Во-вторых, это хоть и популярное, но заблуждение. По-факту, что языки, что фреймворки придерживаются совершенно разных идеологий. И любые ассоциации на тему похожести скорее навредят Вам при изучении Elixir и Phoenix, чем помогут. Хотите ассоциаций — сравнивайте с Erlang и CommonLisp.
Хоть я Вас не минусую, но соглашусь с Fedcomp… Это тупо неуважение к Ruby-сообществу и печально, что Вы при этом прикрываетесь Elixir-сообществом, разжигая неприятие.
Это ведь поэтому наш бизнес не в состоянии конкурировать с общемировым?
Почему именно наш? Это по всему миру так, за редким исключением.
Даже Google решила, что им проще урезанный ЯП разработать, чем в квалификацию программистов вкладываться.
Почему проблема у бизнеса, а решать ее должно образование?
Так забота о населении — это вроде как задача государства, а для бизнеса эта задача в десятом ряду. Поэтому бизнес в среднем исходит из сиюминутных реалий.
Трудовому то народу нужны вполне практичные прогнозы.
"Ну что сказать… Устроены так люди… желают знать что будет"
Только если кабинетные науки хоть какие-то вероятностные прогнозы позволяют делать, то точные прогнозы от гадалок — это совсем другая история. Вообще, это косяк… вместо того, чтобы взять на себя ответственность за будущее, люди постоянно пытаются её на кого-то переложить.
А как насчёт TDD?
Вы «за» или «против»? Что думаете?
TDD vs TLD — это чисто субъективный вопрос. Как писал сам Кент Бек — ему удобно TDD, но это не значит, что все обязаны делать именно так.
На начальном этапе TDD полезнее, т.к. насильно помогает продумывать внутренний API, но для опытных программистов эта часть пользы уходит в ноль. Поэтому если кому-то нравится писать тесты постфактум — я нисколько не возражаю.
А потому стоит громадный вопрос: как лучше всего себя вести в таком состоянии?
Лучше всего игнорировать информационный шум. Это само по себе непросто в крупном городе, но я не понимаю вашего драматизма. Общество всегда пребывает в состоянии, в котором оно никогда до этого не пребывало. Но при этом всегда можно и что-то общее с прошлым найти (спираль истории).
В том числе уметь выявить в этом потоке где полезное, а где мусор
Я об этом с самого начала топика пишу. Что надо обучать полезному (концептуальному и неизменному), чтобы фильтры с детства настраивались… А Вы изначально за мейнстрим/моду/мусор агитировали.
Практика — критерий истины.
С чего вдруг? Исходя из практики можно сделать вывод, что Солнце крутится вокруг Земли и вполне спокойно с этим жить и много лет обходиться без гелиоцентрической системы.
Так же и PHP-программист, клепающий сайты визитки, вполне может, опираясь на свою личную практику, делать вывод, что другие языки в вебе вообще не нужны. Точно так же и Ваша практика ограничивает ваши представления об истине.
И что? От этого программы стали хуже?
Даже не сомневайтесь. Дело не в том, чтобы знать названия, а в том, чтобы понимать концепции, стоящие за этими названиями. Будет ошибкой полагать, что Вы неосознанно использовали концепции ФП, и единственная проблема — незнание названий… Проблема в том, что в силу своего незнания Вы не можете оценить практическую пользу знаний, которыми пока не обладаете. Людям вообще свойственно отстаивать именно свой круг знаний, т.к. нам обычно неприятно признаваться в незнании. Но тут ещё больший парадокс, чем больше знаешь, тем больше осознаёшь масштабы неизвестного. И тут я говорю именно о знаниях, а не об информации.
А потом — клац, и квантовые компьютеры закрывают их часть и открывают другие — и снова учиться.
Такие повороты не исключены. Но тем интереснее, хоть какая-то движуха по существу, а не по синтаксису.
Вертолёт тоже был описан задолго до того, как техника доросла до практической реализации.
OMFG, Вы всерьёз считаете, что event loop и promises впервые появились в JavaScript?
И что ж это за путь?
Осознать, что мейнстрим крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках. Изучить эти концепции и спокойно наслаждаться конкурентным преимуществом в ближайшие 50 лет :-)
Любите Вы передёргивать… Я имею в виду, что после научного прорыва XX века сейчас идёт своеобразный этап стагнации… Человечество сейчас занимается техническим совершенствованием того что есть… помощнее, покомпактнее и т.д., это уже не качественный рост, а плавное усовершенствование существующих технологий.
Но когда в истории людей были такие скоростя роста объёмов информации?
И что? Скорость роста объёмов информации не равна скорости роста знаний и даже не пропорциональна. Вы же понимаете, что более 95% объёма современной информации — это фотки и видосики, из которых 99% даже не учебные, не говоря уж о том, чтобы они несли какие-то новые знания. А оставшиеся 5% почти полностью заняты сектором BigData, который собирает информацию о действиях пользователей на сайтах и т.п.
Стоит ли рассказывать детям, что сейчас модно фоткать еду, снимать котиков, собирать статистику и для этого надо дофига HDD? Да можно, только причём тут обучение познанию?
Вижу, Вы имеете дело с образованием, и далеко не только со стороны студента.
Ну, я скорее имею дело с менторством, как раз как 1000 лет назад xD
мотивация «вам это в будущем понадобится» — крайне неэффективна
Мотивация — это довольно индивидуальная штука, нельзя сказать что «вам это в будущем понадобится» неэффективна, но она не всем подходит, это да. При индивидуальном подходе можно вплетать полезные знания в процесс делания чего-то интересного для конкретного обучаемого. Но опять же у каждого свои интересы, поэтому как универсально это сделать — хз.
Будто слова ООП я не слышал, принципов не знаю и рассказать о них не могу…
Я ж написал, что это утрировано. Тем не менее, про ФП Вы если и слышали, то реально не сможете рассказать, потому что только позавчера путали его с ПП. Про ООП вопрос вообще спорный… Есть целые баталии на тему существует ли оно в мейнстриме вообще или мы наблюдаем лишь слегка модифицированный структурный подход.
Т.е. Вы способны на одних лишь концепциях, без практической реализации в ЯП творить софт?
ЯП в данном вопросе — это просто синтаксис для выражения концепций, синтаксис учится на 3-7 дней, это не проблема. Концепции же надо учить лет 7. И я сам ещё в них не гуру, т.к. года 3 назад ещё считал аналогично Вам, что всё развивается бешенными темпами. И я рад, что пришло осознание того, что это совсем не так. Конечно было бы круто если бы это ещё в школе объясняли, можно было бы сэкономить прилично времени, не изучая ненужное.
Или принцип async/await был расписан 50 лет назад?
Если точно, то в 1976 году. А что?
Мне думается, Ваши претензии как раз в том, что кто-то посмел внедрить какую-то концепцию в какой-то «не тот» язык и имел смелость сказать об этом
У меня вообще претензий к языкам нет. Меня даже вполне устраивает, что новых концепций не появляется… Не придётся постоянно изучать что-то концептуально новое, достаточно один раз изучить существующие наработки. Объём немаленький, но вполне посильный и существенно меньше, чем в других науках. А потом можно и самому о чём-то концептуально новом подумать xD
Люди ищут и будут искать всё более и более удобные формы использования лучших принципов-концепций.
Те, кто реально ищет, не ленится знакомиться с разными вариантами. А большинство просто ждёт пока в их дефолтном ЯП реализуют интересную концепцию хоть в каком-то виде. Даже если косячно реализуют, восторгам не будет предела, см. для примера анонсы pattern matching в C#. Мне в принципе параллельно, пусть радуются. Просто я вижу пути развития получше, чем текущий. Но для этого не надо циклиться на одном ЯП или на одной парадигме, не надо надевать шор.
«Интел выпустил новую линейу процов?? — Пффф!!! Дети! Машина Тьюринга была выпущена полвека назад!»
Предыдущие десятилетия шёл процесс технологического усовершенствования в плане кол-ва транзисторов на единицу площади. Сейчас они упёрлись в физическое ограничение и как бы всё на этом. Т.е. уловите разницу, развитие текущих процессоров — количественное (быстрее/компактнее/etc.). Качественным развитием будут квантовые компьютеры или что-то подобное. Да и это уже про физику, а не про Computer Science.
нужно привлекать чем-то, что реально поможет им на пути к их целям (деньгам)
Ну не знаю. Я верю в человечество, и хочется думать что повёрнутые на деньгах люди — это маргинальное меньшинство. Из таких не получатся ни профессионалы, ни богачи. Потому что деньги — это побочный эффект деятельности, а не её цель.
Да и теории познания тогда такой стройной не было.
Это Вы загнули… Гносеология то чем изменилась за последние пару десятилетий?
руками за собой по своим проектам таскать свои патчи? — зачем, если есть NPM? — опубликовал себе тихоньку то, что тебе надо и пользуешь.
А что npm разве не позволяет подключить репозиторий без создания пакета?
Примерно то же происходит и на гитхабе. Куча практически копий.
Гитхаб не считает форки за отдельные проекты. Так что там всё ok. В принципе, мне без разницы хотят публиковать каждый чих в npm — пусть публикуют. Я просто Вам намекаю, что засорение репозитория пакетов — это минус, а не плюс.
Я, кстати, посмотрел про "закон времени". Собственно, там основная мысль про нарастание информационного шума. Будь то СМИ, соц.сети или npm. Объём знаний не увеличивается так быстро, как они хотят показать. Увеличивается объём мусора. Научить выкапывать из под этого мусора неизменные концепции — это и есть задача современного образования. Если мы поддерживаем у самих себя и у детей иллюзию постоянной гонки — ничего хорошего из этого не выйдет.
Условно говоря, я Вам говорю:
Посмотри, какие классные концепции люди сформулировали в 50-x — 80-x годах прошлого века. Вот языки, в которых можно их пощупать на практике. Если их изучить, то ты качественно вырастешь как профессионал.
А Вы отвечаете:
Отстань, у меня тут ES7 вышел…
Мне надо срочно заменить Math.pow(x, y) на x**y.
Утрировано, конечно. Но смысл именно такой.
В итоге для Вас мейнстрим выглядит как бесконечное развитие, а для меня как вялотекущая имплементация концепций 30-50-летней давности.
Которые, блин, неизменны, как ассоциативность сложения.
Иногда смотришь на мейнстрим-языки и думаешь "ребята, а вы ну хоть что-то новое придумали за предыдущие 20 лет?".
Кто субъект управления этим процессом? — никто?
Коммерческие дистры Linux тоже есть, но это уже сильное отвлечение от темы.
Совершенно верно. И что, это неадекватное желание? Или вложить в проект побольше, писать академической чистоты код 5 лет,
Вы пропустили "при низкой квалификации программистов"… Дело не в академической чистоте, а в том, что текущие программисты в среднем могут пользоваться напильником, но не в состоянии освоить токарный станок. Надо ли объяснять чем было бы быстрее детальки выпиливать?
Но Вы правы, у бизнеса нет свободных ресурсов, чтобы существенно повысить среднюю квалификацию программистов, именно поэтому этим должно образование заниматься.
мой камент повыше
Ну вот, Вы пишете "Самую высокую ценность обретает методология познания нового". Я согласен, но как это сочетается с желанием занять всю школьную программу мейнстримовым примитивом? Если люди с детства будут познавать только смазанные упрощенные концепции, как они научатся познавать новое?
Т.е тупик есть — но в чём его первопрочина, корень?
Имхо, как раз в упрощении программы, насколько мне известно, сейчас в некоторых школах обучение в старших классах свелось к подготовке к ЕГЭ o_O
Нет проблем в самой популярной либе — хорошо. А что делать, если есть?
Очевидно же, исправить и послать pull request. Почему надо сразу писать свою альтернативу?
А с Вашей логикой — выходит — нужно держаться подальше от языков, у которых есть хоть где-то альтернативные реализации чего-либо %)))
Нет, Вы передёргиваете… альтернативы — это хорошо, но ещё лучше когда альтернатив немного. Ну сколько есть способов написать клиент для redis (обычный, с поддержкой full-duplex, с поддержкой cluster, ну и парочку с учётом особенностей ЯП). В идеале хотелось бы иметь все варианты в одном пакете, но даже если будет 5 альтернатив — это ok.
Но что толку от большого кол-ва альтернатив, если 95% из них похожи как под копирку в техническом плане или никому не нужны?
Зачем убунта, если есть дебиан и редхаты и прочее.
Между прочим, это один из основных факторов, который сдерживает популяризацию Linux уже десятки лет. Если бы было меньше 10 дистрибутивов + узкоспециализированные, дело бы шло гораздо быстрее. Сравните с тем же Linux под мобилки… Есть Android и он вполне популярен. Да, там тоже лезут Firefox OS, Ubuntu Touch, MeeGo, etc. Но это уже чисто бизнес, все хотят кусок рынка.
Вы сегодня щедры на похвалы населению :)
Ну, я не утверждал, что все люди ежечасно пользуются своими способностями договариваться и здраво мыслить. Но если отрицать их наличие в принципе, то это ж дурдом получится )))
Ну а если для практики порядок — то учёба это всего-лишь подготовка к этому удобству.
Текущая практика исходит из того, что надо при низкой квалификации программистов сделать побыстрее что-то работающее и не упереться колом в кадровый дефицит, поэтому для неё удобна процедурная парадигма в винегрете с классами и ФВП.
Я бы хотел, чтобы через 20 лет средний уровень программистов был на порядок выше, чем сейчас. А вы (к сожалению не только Вы) по факту хотите чтобы он стал ещё ниже, т.к. даже текущее образование готовы упразднить в пользу сиюминутной моды. В итоге спрос на программистов растёт, а качество обучения постоянно падает. Вот в чём настоящий тупик!
Тяжело то должно быть в ученьи, а не в бою. Если в ученьи прям легко
Легко по моему плану будет вряд ли, зато будет чётко и понятно что к чему.
Но если насчупываются грабли? — то прежде чем упираться в её дебаг — можно посмотреть на другие либы.
OMFG, т.е. мы выбрали самое популярное и подходящее нам решение, но оно оказалось настолько бажным, что проще поискать что-то другое?.. Если бы я ещё не знал JavaScript, Вы меня такими аргументами убедили бы держаться от него как можно дальше :-)
Ну, демократия — это когда каждый сам имеет своё мнение. Не нравится кому-то всё существующее — он пишет своё.
Извините, но это не демократия, это детский сад на уровне "у кого куличик лучше вышел". Зачем тратить время на отдельный проект, когда можно за гораздо меньшее время добавить фичи/исправления в существующий? NIH-синдром или не в меру раздутое ЧСВ?
А если те авторы зашли в реальный тупик и не хотят из него выходить?
Да, такое бывает, но редко. Если авторы существующего решения не ответили в течении месяца на ваш pull request, то это действительно повод задуматься о создании отдельного проекта или форка. Но не убеждайте меня, что авторы всех популярных npm-пакетов забили на поддержку и месяцами на github не заглядывают. Я всё равно в эту версию не поверю :-)
А усилия любого сообщества — в способности договариваться. Если же люди не умеют этого — то всегда будет рознь. Это психология, невзирая на ЯП.
Все люди умеют договариваться и почти все умеют здраво мыслить. Мешает этому, как правило, юношеский максимализм или околорелигиозные предубеждения. От ЯП это не зависит, но способность договариваться характеризует его сообщество.
эээ… но у блокирующего кода нет ивент-лупа…
да, корректнее было сказать несколько потоков, часть из которых под эвент-лупы, а часть — под блокирующий код.
И почему невозможно? Берёшь, не трогаешь переменные — получается ФП. Трогаешь — ПП. Какие проблемы?
Экосистема, начиная со стандартной библиотеки.
И даже если полностью отказаться от стороннего кода, то всё равно будут проблемы с самим языком, т.к. на его уровне нет поддержки важных фич конкретной парадигмы… Попробуйте какую-нибудь парадигму помимо ПП с классами, чтобы понять масштаб проблемы в мейнстрим-языках. К примеру, Smalltalk (ООП) или Haskell (ФП).
Мой вариант:
императивный — это сами переходы между состояниями (типа жд-рельсы между станциями),
а декларативный — это сами состояния (станции).
Не, оба определения не подходят, т.к. императивный стиль подразумевает именно изменение состояния, будь то состояние объекта или глобальные переменные. Предыдущее состояние затирается мгновенно.
Ну а по второму, если бы мы могли сразу указать состояния, то достаточно было бы указать финальное и не писать программу вообще. Вместо этого приходится описывать функции в математическом смысле, т.е. соответствие между множеством аргументов и множеством результатов, другими словами переходы между точками множеств (состояниями). С точки зрения математики, это называется морфизм.
да, поисковик там тот ещё.
Да нормальный поисковик, ну да, может половина выдачи там не является redis клиентами, но другая половина ведь реально является. Т.е., грубо говоря, есть 93 варианта, из которых Вы рассматриваете только 3. Но при этом говорите, что это мегапреимущество, что есть ещё 90 вариантов. Вам не кажется, что соотношение 1 к 30 выглядит как серьёзная проблема в экосистеме, в частности ведущая к сильному распылению усилий сообщества?
Это, скорее, фича :) опция выбора концепции скрипта, чем проблема.
Это была бы фича, если можно было одновременно несколько эвент-лупов запустить, какие-то для блокирующего кода, какие-то для неблокирующего.
Фен-шуй тут ни причём, смотрите простой пример:
Если ЯП позволяет написать функцию, модифицирующую свой аргумент, то это процедурный ЯП.
Если эту функцию необходимо убрать в объект, и модифицировать она будет состояние объекта, то это объектный ЯП.
Если эту функцию в принципе нельзя написать, т.к. данные неизменяемы, то это функциональный ЯП.
Т.к. невозможно выполнить все 3 "если" одновременно, язык должен определиться со своей главной парадигмой.
А теперь код:
function modify(a){ a[0] = 0; }
x = [1, 2, 3];
modify(x);
x == [0, 2, 3]; // => true
def modify(a):
a[0] = 0
x = [1, 2, 3]
modify(x)
x == [0, 2, 3] # => true
Как видно, и JavaScript и Python являются процедурными языками. Да с поддержкой и эмуляцией некоторых фич ООП и ФП, но без ориентации на них. То что разные концепции частично сочетаются в одном языке — это хорошо и удобно для практики, но ужасно для обучения. Сейчас мало кто из программистов понимает, что такое ПП, ООП, ФП… потому что не понимают концепции, а используют какие-то неадекватные критерии, типа "есть классы — значит поддерживает ООП", "есть функции высшего порядка — значит поддерживает ФП". А маркетологи языков на этих мифах успешно ездят.
Хорошо, что лично Вам не помешает.
С Erlang/OTP всё-таки есть прямая связь: Elixir код выполняется на виртуальной машине Erlang, половина его stdlib — обертки над stdlib Erlang, любое приложение на Elixir использует OTP, а Phoenix так вообще очень плотно на OTP опирается.
Что касается Ruby, то связь только такая: на обоих языках приятно программировать и автор Elixir имеет богатый опыт программирования на Ruby. Всё, на этом полезные параллели между Elixir и Ruby заканчиваются.
Во-первых, далеко не любая… Во-вторых, это хоть и популярное, но заблуждение. По-факту, что языки, что фреймворки придерживаются совершенно разных идеологий. И любые ассоциации на тему похожести скорее навредят Вам при изучении Elixir и Phoenix, чем помогут. Хотите ассоциаций — сравнивайте с Erlang и CommonLisp.
Как автор перевода Вы вольны делать что хотите. Но если прикрываетесь сообществом, то не позорьте его.
Не ненависть, а неприятие… Или Вам лично нравится получать спам? Те, кому интересен Elixir подпишутся на Erlang/OTP (пока нет более подходящего хаба)
Хоть я Вас не минусую, но соглашусь с Fedcomp… Это тупо неуважение к Ruby-сообществу и печально, что Вы при этом прикрываетесь Elixir-сообществом, разжигая неприятие.
Почему именно наш? Это по всему миру так, за редким исключением.
Даже Google решила, что им проще урезанный ЯП разработать, чем в квалификацию программистов вкладываться.
Так забота о населении — это вроде как задача государства, а для бизнеса эта задача в десятом ряду. Поэтому бизнес в среднем исходит из сиюминутных реалий.
"Ну что сказать… Устроены так люди… желают знать что будет"
Только если кабинетные науки хоть какие-то вероятностные прогнозы позволяют делать, то точные прогнозы от гадалок — это совсем другая история. Вообще, это косяк… вместо того, чтобы взять на себя ответственность за будущее, люди постоянно пытаются её на кого-то переложить.
TDD vs TLD — это чисто субъективный вопрос. Как писал сам Кент Бек — ему удобно TDD, но это не значит, что все обязаны делать именно так.
На начальном этапе TDD полезнее, т.к. насильно помогает продумывать внутренний API, но для опытных программистов эта часть пользы уходит в ноль. Поэтому если кому-то нравится писать тесты постфактум — я нисколько не возражаю.
Лучше всего игнорировать информационный шум. Это само по себе непросто в крупном городе, но я не понимаю вашего драматизма. Общество всегда пребывает в состоянии, в котором оно никогда до этого не пребывало. Но при этом всегда можно и что-то общее с прошлым найти (спираль истории).
Я об этом с самого начала топика пишу. Что надо обучать полезному (концептуальному и неизменному), чтобы фильтры с детства настраивались… А Вы изначально за мейнстрим/моду/мусор агитировали.
С чего вдруг? Исходя из практики можно сделать вывод, что Солнце крутится вокруг Земли и вполне спокойно с этим жить и много лет обходиться без гелиоцентрической системы.
Так же и PHP-программист, клепающий сайты визитки, вполне может, опираясь на свою личную практику, делать вывод, что другие языки в вебе вообще не нужны. Точно так же и Ваша практика ограничивает ваши представления об истине.
Даже не сомневайтесь. Дело не в том, чтобы знать названия, а в том, чтобы понимать концепции, стоящие за этими названиями. Будет ошибкой полагать, что Вы неосознанно использовали концепции ФП, и единственная проблема — незнание названий… Проблема в том, что в силу своего незнания Вы не можете оценить практическую пользу знаний, которыми пока не обладаете. Людям вообще свойственно отстаивать именно свой круг знаний, т.к. нам обычно неприятно признаваться в незнании. Но тут ещё больший парадокс, чем больше знаешь, тем больше осознаёшь масштабы неизвестного. И тут я говорю именно о знаниях, а не об информации.
Такие повороты не исключены. Но тем интереснее, хоть какая-то движуха по существу, а не по синтаксису.
OMFG, Вы всерьёз считаете, что event loop и promises впервые появились в JavaScript?
Осознать, что мейнстрим крайне медлительно заимствует концепции, которые давным давно сформулированы и реализованы в чуть менее популярных языках. Изучить эти концепции и спокойно наслаждаться конкурентным преимуществом в ближайшие 50 лет :-)
Если почитать биографии известных миллионеров, то окажется, что это не совсем так.
Это да, поэтому астрология и хиромантия гораздо популярнее любой теории познания..
Любите Вы передёргивать… Я имею в виду, что после научного прорыва XX века сейчас идёт своеобразный этап стагнации… Человечество сейчас занимается техническим совершенствованием того что есть… помощнее, покомпактнее и т.д., это уже не качественный рост, а плавное усовершенствование существующих технологий.
И что? Скорость роста объёмов информации не равна скорости роста знаний и даже не пропорциональна. Вы же понимаете, что более 95% объёма современной информации — это фотки и видосики, из которых 99% даже не учебные, не говоря уж о том, чтобы они несли какие-то новые знания. А оставшиеся 5% почти полностью заняты сектором BigData, который собирает информацию о действиях пользователей на сайтах и т.п.
Стоит ли рассказывать детям, что сейчас модно фоткать еду, снимать котиков, собирать статистику и для этого надо дофига HDD? Да можно, только причём тут обучение познанию?
Ну, я скорее имею дело с менторством, как раз как 1000 лет назад xD
Мотивация — это довольно индивидуальная штука, нельзя сказать что «вам это в будущем понадобится» неэффективна, но она не всем подходит, это да. При индивидуальном подходе можно вплетать полезные знания в процесс делания чего-то интересного для конкретного обучаемого. Но опять же у каждого свои интересы, поэтому как универсально это сделать — хз.
Я ж написал, что это утрировано. Тем не менее, про ФП Вы если и слышали, то реально не сможете рассказать, потому что только позавчера путали его с ПП. Про ООП вопрос вообще спорный… Есть целые баталии на тему существует ли оно в мейнстриме вообще или мы наблюдаем лишь слегка модифицированный структурный подход.
ЯП в данном вопросе — это просто синтаксис для выражения концепций, синтаксис учится на 3-7 дней, это не проблема. Концепции же надо учить лет 7. И я сам ещё в них не гуру, т.к. года 3 назад ещё считал аналогично Вам, что всё развивается бешенными темпами. И я рад, что пришло осознание того, что это совсем не так. Конечно было бы круто если бы это ещё в школе объясняли, можно было бы сэкономить прилично времени, не изучая ненужное.
Если точно, то в 1976 году. А что?
У меня вообще претензий к языкам нет. Меня даже вполне устраивает, что новых концепций не появляется… Не придётся постоянно изучать что-то концептуально новое, достаточно один раз изучить существующие наработки. Объём немаленький, но вполне посильный и существенно меньше, чем в других науках. А потом можно и самому о чём-то концептуально новом подумать xD
Те, кто реально ищет, не ленится знакомиться с разными вариантами. А большинство просто ждёт пока в их дефолтном ЯП реализуют интересную концепцию хоть в каком-то виде. Даже если косячно реализуют, восторгам не будет предела, см. для примера анонсы pattern matching в C#. Мне в принципе параллельно, пусть радуются. Просто я вижу пути развития получше, чем текущий. Но для этого не надо циклиться на одном ЯП или на одной парадигме, не надо надевать шор.
Предыдущие десятилетия шёл процесс технологического усовершенствования в плане кол-ва транзисторов на единицу площади. Сейчас они упёрлись в физическое ограничение и как бы всё на этом. Т.е. уловите разницу, развитие текущих процессоров — количественное (быстрее/компактнее/etc.). Качественным развитием будут квантовые компьютеры или что-то подобное. Да и это уже про физику, а не про Computer Science.
Ну не знаю. Я верю в человечество, и хочется думать что повёрнутые на деньгах люди — это маргинальное меньшинство. Из таких не получатся ни профессионалы, ни богачи. Потому что деньги — это побочный эффект деятельности, а не её цель.
Это Вы загнули… Гносеология то чем изменилась за последние пару десятилетий?
А что npm разве не позволяет подключить репозиторий без создания пакета?
Гитхаб не считает форки за отдельные проекты. Так что там всё ok. В принципе, мне без разницы хотят публиковать каждый чих в npm — пусть публикуют. Я просто Вам намекаю, что засорение репозитория пакетов — это минус, а не плюс.
Я, кстати, посмотрел про "закон времени". Собственно, там основная мысль про нарастание информационного шума. Будь то СМИ, соц.сети или npm. Объём знаний не увеличивается так быстро, как они хотят показать. Увеличивается объём мусора. Научить выкапывать из под этого мусора неизменные концепции — это и есть задача современного образования. Если мы поддерживаем у самих себя и у детей иллюзию постоянной гонки — ничего хорошего из этого не выйдет.
Условно говоря, я Вам говорю:
Посмотри, какие классные концепции люди сформулировали в 50-x — 80-x годах прошлого века. Вот языки, в которых можно их пощупать на практике. Если их изучить, то ты качественно вырастешь как профессионал.
А Вы отвечаете:
Отстань, у меня тут ES7 вышел…
Мне надо срочно заменить
Math.pow(x, y)наx**y.Утрировано, конечно. Но смысл именно такой.
В итоге для Вас мейнстрим выглядит как бесконечное развитие, а для меня как вялотекущая имплементация концепций 30-50-летней давности.
Которые, блин, неизменны, как ассоциативность сложения.
Иногда смотришь на мейнстрим-языки и думаешь "ребята, а вы ну хоть что-то новое придумали за предыдущие 20 лет?".
Коммерческие дистры Linux тоже есть, но это уже сильное отвлечение от темы.
Вы пропустили "при низкой квалификации программистов"… Дело не в академической чистоте, а в том, что текущие программисты в среднем могут пользоваться напильником, но не в состоянии освоить токарный станок. Надо ли объяснять чем было бы быстрее детальки выпиливать?
Но Вы правы, у бизнеса нет свободных ресурсов, чтобы существенно повысить среднюю квалификацию программистов, именно поэтому этим должно образование заниматься.
Ну вот, Вы пишете "Самую высокую ценность обретает методология познания нового". Я согласен, но как это сочетается с желанием занять всю школьную программу мейнстримовым примитивом? Если люди с детства будут познавать только смазанные упрощенные концепции, как они научатся познавать новое?
Имхо, как раз в упрощении программы, насколько мне известно, сейчас в некоторых школах обучение в старших классах свелось к подготовке к ЕГЭ o_O
Очевидно же, исправить и послать pull request. Почему надо сразу писать свою альтернативу?
Нет, Вы передёргиваете… альтернативы — это хорошо, но ещё лучше когда альтернатив немного. Ну сколько есть способов написать клиент для redis (обычный, с поддержкой full-duplex, с поддержкой cluster, ну и парочку с учётом особенностей ЯП). В идеале хотелось бы иметь все варианты в одном пакете, но даже если будет 5 альтернатив — это ok.
Но что толку от большого кол-ва альтернатив, если 95% из них похожи как под копирку в техническом плане или никому не нужны?
Между прочим, это один из основных факторов, который сдерживает популяризацию Linux уже десятки лет. Если бы было меньше 10 дистрибутивов + узкоспециализированные, дело бы шло гораздо быстрее. Сравните с тем же Linux под мобилки… Есть Android и он вполне популярен. Да, там тоже лезут Firefox OS, Ubuntu Touch, MeeGo, etc. Но это уже чисто бизнес, все хотят кусок рынка.
Ну, я не утверждал, что все люди ежечасно пользуются своими способностями договариваться и здраво мыслить. Но если отрицать их наличие в принципе, то это ж дурдом получится )))
Текущая практика исходит из того, что надо при низкой квалификации программистов сделать побыстрее что-то работающее и не упереться колом в кадровый дефицит, поэтому для неё удобна процедурная парадигма в винегрете с классами и ФВП.
Я бы хотел, чтобы через 20 лет средний уровень программистов был на порядок выше, чем сейчас. А вы (к сожалению не только Вы) по факту хотите чтобы он стал ещё ниже, т.к. даже текущее образование готовы упразднить в пользу сиюминутной моды. В итоге спрос на программистов растёт, а качество обучения постоянно падает. Вот в чём настоящий тупик!
Легко по моему плану будет вряд ли, зато будет чётко и понятно что к чему.
OMFG, т.е. мы выбрали самое популярное и подходящее нам решение, но оно оказалось настолько бажным, что проще поискать что-то другое?.. Если бы я ещё не знал JavaScript, Вы меня такими аргументами убедили бы держаться от него как можно дальше :-)
Извините, но это не демократия, это детский сад на уровне "у кого куличик лучше вышел". Зачем тратить время на отдельный проект, когда можно за гораздо меньшее время добавить фичи/исправления в существующий? NIH-синдром или не в меру раздутое ЧСВ?
Да, такое бывает, но редко. Если авторы существующего решения не ответили в течении месяца на ваш pull request, то это действительно повод задуматься о создании отдельного проекта или форка. Но не убеждайте меня, что авторы всех популярных npm-пакетов забили на поддержку и месяцами на github не заглядывают. Я всё равно в эту версию не поверю :-)
Все люди умеют договариваться и почти все умеют здраво мыслить. Мешает этому, как правило, юношеский максимализм или околорелигиозные предубеждения. От ЯП это не зависит, но способность договариваться характеризует его сообщество.
да, корректнее было сказать несколько потоков, часть из которых под эвент-лупы, а часть — под блокирующий код.
Правда, не все авторы таких примеров сами понимают монады :-)
У Вирта было
a := b+cИ даже если полностью отказаться от стороннего кода, то всё равно будут проблемы с самим языком, т.к. на его уровне нет поддержки важных фич конкретной парадигмы… Попробуйте какую-нибудь парадигму помимо ПП с классами, чтобы понять масштаб проблемы в мейнстрим-языках. К примеру, Smalltalk (ООП) или Haskell (ФП).
Ну а по второму, если бы мы могли сразу указать состояния, то достаточно было бы указать финальное и не писать программу вообще. Вместо этого приходится описывать функции в математическом смысле, т.е. соответствие между множеством аргументов и множеством результатов, другими словами переходы между точками множеств (состояниями). С точки зрения математики, это называется морфизм.
Да нормальный поисковик, ну да, может половина выдачи там не является redis клиентами, но другая половина ведь реально является. Т.е., грубо говоря, есть 93 варианта, из которых Вы рассматриваете только 3. Но при этом говорите, что это мегапреимущество, что есть ещё 90 вариантов. Вам не кажется, что соотношение 1 к 30 выглядит как серьёзная проблема в экосистеме, в частности ведущая к сильному распылению усилий сообщества?
Это была бы фича, если можно было одновременно несколько эвент-лупов запустить, какие-то для блокирующего кода, какие-то для неблокирующего.
Фен-шуй тут ни причём, смотрите простой пример:
Если ЯП позволяет написать функцию, модифицирующую свой аргумент, то это процедурный ЯП.
Если эту функцию необходимо убрать в объект, и модифицировать она будет состояние объекта, то это объектный ЯП.
Если эту функцию в принципе нельзя написать, т.к. данные неизменяемы, то это функциональный ЯП.
Т.к. невозможно выполнить все 3 "если" одновременно, язык должен определиться со своей главной парадигмой.
А теперь код:
Как видно, и JavaScript и Python являются процедурными языками. Да с поддержкой и эмуляцией некоторых фич ООП и ФП, но без ориентации на них. То что разные концепции частично сочетаются в одном языке — это хорошо и удобно для практики, но ужасно для обучения. Сейчас мало кто из программистов понимает, что такое ПП, ООП, ФП… потому что не понимают концепции, а используют какие-то неадекватные критерии, типа "есть классы — значит поддерживает ООП", "есть функции высшего порядка — значит поддерживает ФП". А маркетологи языков на этих мифах успешно ездят.