Любите Вы передёргивать… Я имею в виду, что после научного прорыва 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 являются процедурными языками. Да с поддержкой и эмуляцией некоторых фич ООП и ФП, но без ориентации на них. То что разные концепции частично сочетаются в одном языке — это хорошо и удобно для практики, но ужасно для обучения. Сейчас мало кто из программистов понимает, что такое ПП, ООП, ФП… потому что не понимают концепции, а используют какие-то неадекватные критерии, типа "есть классы — значит поддерживает ООП", "есть функции высшего порядка — значит поддерживает ФП". А маркетологи языков на этих мифах успешно ездят.
алгоритмы (программы) как таковые — это пути перехода между какими-то состояниями
О, Вы мне напомнили ещё одно отличие между императивным и декларативным подходами. Императивный описывает процесс изменения состояния, а декларативный — процесс перехода между состояниями.
Конечно же, это всё мои предпочтения. И всё, что я пытаюсь — это вызвать здравый огонь критики в адрес этого выбора.
Ну как же я могу критиковать CoffeeScript, он же вдохновлён примером Ruby. А на Ruby я программировал аж 8 лет :-)
Разве что злоупотребляете poetry mode..
Уже отсеиваю их за считанные минуты. Зато есть выбор.
Зашёл ради интереса на npmjs поискать клиент для redis и "193 results for ‘redis client’" и при этом даже сортировки по кол-ву звёзд нет… Уже начинаю завидовать Вашей скорости анализа сторонних библиотек.
Было куда хуже, когда программел асинхронность на питоновском твистеде
Да я за питон нигде не агитировал. И даже согласен, что GIL в текущих реалиях уже тоже шоустопер. Впрочем, эвент-луп JS от блокирующих операций пока не защищен и это тоже проблема.
Наверно потому, что быстро делать не то, что нужно, никому не надо…
И почему сравнение некорректное? И то и то будет правильно работать в некоторых случаях.
я ж уже просил пример другого какого языка, на котором можно было бы программить почти на всём мыслимом железе
А на каком языке сейчас нельзя? Упомянутые Вами малинки потянут что угодно из компилируемых ЯП, они даже интерпретируемые типа JavaScript тянут. Вообще идея для всего использовать один язык — это как раз та история про плотника с молотком. Ну можно на JS писать под десктоп (Electron), но это ж тихий ужас… Приложение весит 100+ Mb, и память жрёт не хуже, чем браузер. Не у всех на десктопе по 16 Gb оперативы… тот же C# на десктопе JS уделывает как тузик грелку.
Поэтому чем тут мериться? Тем что "для галочки" везде можно использовать?
Дескать, всё что есть из популярного — всё чисто недопиленные позёрские поделия…
Причём тут позёрство? К примеру, чисто технически невозможно сделать одновременно функциональноориентированный и объектноориентированный язык. Хотя бы потому что в для первого — необходимо передавать состояние функциям, а для второго слать сообщения "состоянию"(объектам).
Можно частично использовать ООП и ФП совместно, но нельзя ориентировать один язык сразу на 2 парадигмы. Всё равно одна будет ведущей, а другие — частично поддерживаемы.
Там по ссылке какая-то жесть… история, биология, геофизика и т.д. — это тоже разделы математики?
ФП — это раздел дискретной математики, там всё понятно.
Императивное программирование же искажает базовые математические понятия — функция, значение, etc.
Да какой чит? Конечно же кофескрипт.
С чего вдруг "конечно же"? Вы недавно про ES6/7 писали… А какая вам вообще печаль, что там в ES творится, если Вы по факту другой язык используете? Да и почему "конечно же кофескрипт"? Почему не TypeScript или не PureScript или не ClojureScript или ещё пара десятков вариантов? Вы свой личный выбор выдаёте за что-то дефолтное.
Но сути это не меняет.
Суть в том, что при выборе каждого пакета, Вам придётся сталкиваться с буридановым выбором.
Т.е. Вы мотивируете отсутствие корректной реализации тем, что она медленнее некорректной?
Давайте по такому же принципу вместо сортировки будем только первые 2 элемента сравнивать, так ведь быстрее.
Как в вашу императивную картину мира вписываются такие факты:
Twitter выбрал Scala, WhatsApp — Erlang, Facebook — написал свой язык.
Сложность проектов и требования к ним растут, текущий мейнстрим — это временное явление, впрочем как всегда.
По-моему Вы боитесь, что люди после школы будут знать больше полезного, чем большинство текущих программистов. Поэтому хотите их учить тому, что наверняка уж устареет и как можно быстрее :-)
Где, кроме суровых железных ограничений, придётся пойти на «жёсткий компромисс» и выбрать моно-язык какой, без того же ООП, а оно в проекте нужно?
Вы не поняли… на компромиссы приходится идти дизайнерам языка, чтобы вписать в него несколько взаимоисключающих парадигм. В итоге ни одна не реализована толком, но какие-то отдельные фичи можно юзать.
Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 2 диаметрально противоположных мира )))
Вообще, про читабельность я сравнивал (positive? n) и (> n 0)…
(n > 0) и (> n 0) на мой взгляд эквивалентны по читаемости, просто второй вариант непривычен, зато единообразен — функция всегда на первом месте.
Алгоритм один и тот же, но букаф — очень разное к-во.
Ладно, я следаю вид, что не заметил Ваш чит с подменой JS на кофе, т.к. очевидно, что в JS скобок было бы ничуть не меньше, чем в Racket.
И нужно сравнивать экосистемы языков. Ибо вот писать с нуля какую-нить либу — это вот уже боль.
У экосистемы Node.JS leftpad-синдром. При этом даже Вы преподносите число пакетов в N раз превышающее кол-во пакетов под Python как плюс. Вы даже не задумываетесь насколько это жирный минус. Задумайтесь, откуда берётся эта разница? Думаете JS решает в N раз больше задач, как бы не так...
Ну, если у скрипта поменять шабанг — то тоже можно получить очень даже другой язык :)
Да, только тут то язык остался тот же. Так можно сочетать разные концепции в рамках одного языка, не нарушая чистоту концепции. Имхо, для обучения — это прекрасный вариант.
Любите Вы передёргивать… Я имею в виду, что после научного прорыва 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 являются процедурными языками. Да с поддержкой и эмуляцией некоторых фич ООП и ФП, но без ориентации на них. То что разные концепции частично сочетаются в одном языке — это хорошо и удобно для практики, но ужасно для обучения. Сейчас мало кто из программистов понимает, что такое ПП, ООП, ФП… потому что не понимают концепции, а используют какие-то неадекватные критерии, типа "есть классы — значит поддерживает ООП", "есть функции высшего порядка — значит поддерживает ФП". А маркетологи языков на этих мифах успешно ездят.
Скорее автомобиль, который приезжал бы в два (далёких друг от друга) пункта назначения одновременно.
О, Вы мне напомнили ещё одно отличие между императивным и декларативным подходами. Императивный описывает процесс изменения состояния, а декларативный — процесс перехода между состояниями.
Ну как же я могу критиковать CoffeeScript, он же вдохновлён примером Ruby. А на Ruby я программировал аж 8 лет :-)
Разве что злоупотребляете poetry mode..
Зашёл ради интереса на npmjs поискать клиент для redis и "193 results for ‘redis client’" и при этом даже сортировки по кол-ву звёзд нет… Уже начинаю завидовать Вашей скорости анализа сторонних библиотек.
Да я за питон нигде не агитировал. И даже согласен, что GIL в текущих реалиях уже тоже шоустопер. Впрочем, эвент-луп JS от блокирующих операций пока не защищен и это тоже проблема.
Наверно потому, что быстро делать не то, что нужно, никому не надо…
И почему сравнение некорректное? И то и то будет правильно работать в некоторых случаях.
Мимо, имелась кодовая база и куча спецов на Ruby.
А помните как переводили кодовую базу? https://github.com/facebookarchive/lex-pass/tree/master
А на каком языке сейчас нельзя? Упомянутые Вами малинки потянут что угодно из компилируемых ЯП, они даже интерпретируемые типа JavaScript тянут. Вообще идея для всего использовать один язык — это как раз та история про плотника с молотком. Ну можно на JS писать под десктоп (Electron), но это ж тихий ужас… Приложение весит 100+ Mb, и память жрёт не хуже, чем браузер. Не у всех на десктопе по 16 Gb оперативы… тот же C# на десктопе JS уделывает как тузик грелку.
Поэтому чем тут мериться? Тем что "для галочки" везде можно использовать?
Причём тут позёрство? К примеру, чисто технически невозможно сделать одновременно функциональноориентированный и объектноориентированный язык. Хотя бы потому что в для первого — необходимо передавать состояние функциям, а для второго слать сообщения "состоянию"(объектам).
Можно частично использовать ООП и ФП совместно, но нельзя ориентировать один язык сразу на 2 парадигмы. Всё равно одна будет ведущей, а другие — частично поддерживаемы.
Там по ссылке какая-то жесть… история, биология, геофизика и т.д. — это тоже разделы математики?
ФП — это раздел дискретной математики, там всё понятно.
Императивное программирование же искажает базовые математические понятия — функция, значение, etc.
С чего вдруг "конечно же"? Вы недавно про ES6/7 писали… А какая вам вообще печаль, что там в ES творится, если Вы по факту другой язык используете? Да и почему "конечно же кофескрипт"? Почему не TypeScript или не PureScript или не ClojureScript или ещё пара десятков вариантов? Вы свой личный выбор выдаёте за что-то дефолтное.
Суть в том, что при выборе каждого пакета, Вам придётся сталкиваться с буридановым выбором.
Т.е. Вы мотивируете отсутствие корректной реализации тем, что она медленнее некорректной?
Давайте по такому же принципу вместо сортировки будем только первые 2 элемента сравнивать, так ведь быстрее.
Как в вашу императивную картину мира вписываются такие факты:
Twitter выбрал Scala, WhatsApp — Erlang, Facebook — написал свой язык.
Сложность проектов и требования к ним растут, текущий мейнстрим — это временное явление, впрочем как всегда.
По-моему Вы боитесь, что люди после школы будут знать больше полезного, чем большинство текущих программистов. Поэтому хотите их учить тому, что наверняка уж устареет и как можно быстрее :-)
Вы не поняли… на компромиссы приходится идти дизайнерам языка, чтобы вписать в него несколько взаимоисключающих парадигм. В итоге ни одна не реализована толком, но какие-то отдельные фичи можно юзать.
У, Вы сами себя в угол загнали… см. выше коммент про ФП.
Где императивное программирование, а где математика — это ж 2 диаметрально противоположных мира )))
Вообще, про читабельность я сравнивал (positive? n) и (> n 0)…
(n > 0) и (> n 0) на мой взгляд эквивалентны по читаемости, просто второй вариант непривычен, зато единообразен — функция всегда на первом месте.
Ладно, я следаю вид, что не заметил Ваш чит с подменой JS на кофе, т.к. очевидно, что в JS скобок было бы ничуть не меньше, чем в Racket.
У экосистемы Node.JS leftpad-синдром. При этом даже Вы преподносите число пакетов в N раз превышающее кол-во пакетов под Python как плюс. Вы даже не задумываетесь насколько это жирный минус. Задумайтесь, откуда берётся эта разница? Думаете JS решает в N раз больше задач, как бы не так...
Да, только тут то язык остался тот же. Так можно сочетать разные концепции в рамках одного языка, не нарушая чистоту концепции. Имхо, для обучения — это прекрасный вариант.