по-моему Вы не очень понимаете, что такое иммутабельность данных
Ну да это уже детали. Брать и просто не менять единожды созданное, или как-то самоограничиться с помощью средств языка. В итоге разницы практически нет.
Вы просто не представляете объём сторонних библиотек и прочей инфы, по языкам, с которыми не знакомы…
Знал бы — зачем бы тогда спрашивал?
Потому и говорю, что нужно сравнивать экосистемы языков.
Ничего страшного.
Наложить кучу… кхм… в голову людям, которые через 15-20 лет возьмут бразды правления страной в руки — сущие пустяки!
По факту всё так и есть,
"- Так Вам нужна программа с применением ООП?
— Для тупых повторяю: рация сломалась на танке"
Но по факту мы не наблюдаем монополии какого-либо языка на всякую концепцию. Формирование обратного представления у детей — это гадить им в жизнь, своим детям и внукам, ну и себе в старости.
но это в реальности достигается путём уступок и жёстких компромиссов.
«Эх… на чём же писать-то?? ООП на сях или ООП на питоне??.. железа много — можно на питоне»
Примеры?
Где, кроме суровых железных ограничений, придётся пойти на «жёсткий компромисс» и выбрать моно-язык какой, без того же ООП, а оно в проекте нужно?
Почти все популярные языки нонче — мульти. Т.е. языка — это уже ф-ция от желания заказчика и наличия специалистов и даже немного :) от специфики задачи.
А как Вы предлагаете выбирать язык, наиболее подходящий под задачу
Если существующий проект — то боль и вопрос языка закрыт (разве что речь о «всё по-новой»).
Если проект новый/перепись — то выбор начинается.
Окинуть взором веб на предмет возможных вариантов/новинок/тенденций в ЯП (кстати, отдельными языками можно и нужно считать даже сторонние библиотеки, ибо это отдельный набор терминов и функционал).
Если долгосрочный — то важны затраты на поддержку: внесение изменений должно быть простым (быстрым и дешёвым) — нечто достаточно популярное и/ли с растущей популярностью (чтоб спецы на нём были по безоблачным ценам).
На этапе реализации основные затраты — это время людей. И они его не должны тратить на специфику специфичного чего-то без надобности. Т.е. приоритет тому, что уже знают (а знают, вероятнее всего — нечто популярное; а популярность в ЯП не падает с неба), либо то, что есть смысл изучить ввиду растущей популяpрности (проект то не последний).
Ну а дальше всё просто:
сервак/PC — где железа поболе — скриптовый ЯП высокого уровня (JS — фактически, уже без вариантов),
если железа мало/критичная скорость — то компилируемый язык: Go или С (ну максимум с асм вставками).
Если веб — ну совсем понятно (флеш или жаба-аплеты — уже всё).
Мобила — как и на десктопе (с поправкой, что низким уровнем может быть и андроидная жаба).
Ну а если какие ардуины многоногие — то там выбор не так широк.
Если ж нормальную ОСь там можно пустить («малинки» и ко) и по скорости/мозгам некритично — то можно сохранить время людей, взяв привычный ЯП высокого уровня (нода крутится на таком без вопросов).
Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика. И там оператор — между операндами.
Имхо, не в пользу CoffeeScript…
Конечно же, это дело привычки. Но чем меньше информации нужно получить (и обработать) для понимания смысла — тем читабельность лучше.
Если не согласны — можем сравнить текст на С со скомпиленным бинарём в HEX'е ;)
Алгоритм один и тот же, но букаф — очень разное к-во.
freeze above t, beside t, t — вообще нечитаемо.
Можно добавлять скобочек поначалу, пока появится привычка:
freeze above t, beside(t, t)
или
freeze above(t, beside(t, t))
или
freeze(above(t, beside(t, t)))
(последний вариант Вам должен понравиться ;) скобочек так, поболе)
Снова же дело привычки. Но есть потенциал роста скорости набора программы путём уменьшения объёма вводимой инфы (символов) при неизменной окончательной логике.
Собсно, это и есть смысл синтактического сахара как такового. Ну и, понятно, не все исторические языки затачивались под это.
для JavaScript я не видел библиотек, похожих на стандартную поставку Racket
Ну это вообще в стиле холивара «какой линух дистр лучше: с опенофисом по умолчанию или без». Так можно и какое-нить руби взять и померять пиписк*ми с ракетой или ещё чем.
Благо, на дворе не оффлайн 90-хх и дистр с языком друг принёс на компакте. Что надо — берётся и ставится.
И нужно сравнивать экосистемы языков. Ибо вот писать с нуля какую-нить либу — это вот уже боль.
npm-пакетов неизвестного качества.
Как я понимаю, каждую строчку исходников и качество кода ракет дистрибутива Вы лично проверяете перед использованием…
Тогда молчу :)
Её можно заменить на другую и получить язык с другим набором концепций, т.е. они не навалены все в одну кучу. Например "#lang typed/racket"
Ну, если у скрипта поменять шабанг — то тоже можно получить очень даже другой язык :)
Заведомо — неопределённо.
Равно равности двух случайных чисел.
Два разных вызова дадут разные случайные числа — потому в общем виде более точного ответа не дать.
Вы, видимо, путаете «процедурно» и «функционально»
Возможно. Но если из результата работы процедуры взять и получить результат — то это уже прям меняет парадигму программирования? Даже если — то что? :)
Вот я думаю, что ровно ничего. Наличие у подпрограммы входных и выходных параметров — это более общий случай отсутствия первых или вторых. Как бы это ни называлось.
Невольно подтверждая мой тезис о том, что концептуального образования дико не хватает.
Кому? %)
Даже профессиональные программисты частенько путаются в элементарных вещах.
Получил значение выходного параметра — нужно записать в дневную отчётность: «воспользовался функциональной парадигмой»?
Вам шашечки или ехать?
в питоне есть мутабельные данные, этого уже достаточно для невозможности писать в чисто функциональном стиле и использовать стандартную библиотеку одновременно.
Разогрет и буду благодарен за реальный пример.
Сам бы может и накопал чего, но «мутабельные данные» — это же просто переменные данные, ну а в память записать значение можно на очень многих языках. И ну не вижу почему это может мешать функциональному программированию.
Т.е. свежие ES6 и ES7, введшие множество фич и синтаксического сахара (движение к питон-стилю синтаксиса) — Вы не рассматриваете как развитие?
Просто хочу либо какой-то конкретики про JS (почему он так уж плох), либо простое «да пофиг на него просто».
через 10 лет это будет совсем другой язык.
Ну и на здоровье. Не улучшать что-то только для того, чтобы не менять… эээ? :)
Ну либо Вы в состоянии показать заведомо идеальный и давно неизменный ЯП?
всё упирается в центральный однопоточный event-loop.
Да, счас этого может уже быть и маловато. Но в той же ноде есть искаробки модуль для распараллеливания вширь. Нормальный такой костыль, пока ядро однопоточное (но всё же меняется… ;)
Сравните с Erlang/Elixir
Вполне возможно, оно там как-то лучше завёрнуто (изначально в ТЗ на язык, видать, было так), но где тогда их распространённость?
На ерланге я знаю целую софтину (ejabberd) и либу распределённого хранения (кажись) mnesia…
Понятно, что маркетинг круче технического совершенства, но нода появилась не из-за маркетинга. Жабоскрипт сумел выйти из браузера в переполненную и чрезвычайно конкурентную среду серверного программирования (в виде ноды). В 2009. А сколько лет обозначенным языкам? Почему у них так негуст рынок при такой то архитектуре?
Вобщем, как я вижу: может по отдельным «концепциям» вполне возможно найти какие-то более удачные варианты, но суммарно по всем возможностям и экосистеме, которая на сегодня есть у жабоскрипта — вопрос о скриптовых языках закрыт надолго.
На каком ещё языке можно:
* писать асинхронно из коробки (без доп. либ)
* писать на всех (всех) мыслимых платформах: сервер, браузер, десктоп, мобил и даже всякие «малинки»
* иметь такую громадину готовых сторонних либ (более 200к либ только на npmjs, пусть даже не всё там для js, это с 2009; для сравнения: у синхронного питона на pypi около 70к либ, но с 1992 года(!!!)), и все эти либы — автоматически асинхронны, вопрос уместить в одном процессе разные сервера в принципе не стоит
Если можно — то, прошу, больше конкретики, без туманных терминов, типа «колбасит».
Если же просто неприятие жабосрипта (ещё год назад я плевался, примерно, как Вы счас) — то это тоже принимается. Никого к стенке прижимать я цели не имею, просто хочу узнать всякую конструктивную критику жабоскрипта и производных кофей (мне ж это в массы нести).
Вот и смотрите, как эффективно занять 100 ядер вычислениями и не попасть на race condition? Нужны иммутабельные данные.
Ну и для эффективного использования 100 ядер нужно просто обеспечить беспроблемность в их совместной работе. Если имеют место общие данные — то нужна синхронизация (кстати неизменные переменные — это частный случай, когда запись в переменную вообще запрещена всегда; кстати, оператор const в других языках никто не отменял).
Так что только из-за иммутабельности выбирать для проекта (в том числе обучение) язык 3-го эшелона — неразумно. Объём сторонних библиотек и прочей инфы — всё это списать со счетов популярных языков только из-за одной фичи — не вариант. В том числе изучать редкий язык только из-за одной фичи для демонстрации одной из концепций — тоже не вариант. У учеников сложится впечатление, что «за ООП — это идти к ЯП1, функциональное — это к ЯП2, а эффективно использовать проц — это к ЯП3». Т.е. концепция демонстируется не сама со себе в таком случае, а вместе со всё новым языком. Наглядность улетучивается.
Гормоны (точнее генетические программы) всю жизнь давят на мозг. И тут уж вопрос развития самого человека: вырастет ли он до чего-то, что было бы важнее в его алгоритмие, чем генетические программы (покушать, поспать, кайфонуть, размножиться).
это не смайлик, а 6 (ШЕСТЬ!!!) закрывающих скобочек.
Но зашоренность сознания привычным С-like синтаксисом
C тут непричём. Копаем глубже. Где в жизни люди впервые применяют операторы сравнения меньше, больше и т.д.? — в школе.
И как они там выглядят? функциями «zero?» или «positive?»? — нет, математическим языком оно записывается знаками. Вполне логично и компьютеру писать программу такими же знаками (привычнее) и даже короче:
positive? n
11 символов
vs
N > 0
5 символов
И «zero? n» vs «n == 0» — 7 и 6 символов соотв.
Больше букв, к тому же нематематического синтаксиса.
Фракталы — это, конечно, просто отлично. Но рекурсия для этого есть не только в лиспах (впрочем, в ракете интересный подход, когда можно объявить ф-цию и тем же самым её вызвать: по сути, это скрытый оператор goto). Но синтаксис… просто жуть. Столько лишних (скобочек (в [самых] разных (местах)) ('просто?) кошмар)
Теперь прикиньте сколько кода писать на JS пришлось бы для того же результата :-D
Давайте прикинем. Кофескрипт. И для чистоты эксперимента буду пользовать либу с тем же именем и теми же ф-циями:
require '2htdp/image'
sierpinski = (n) ->
if n == 0
triangle 2, solid, red
else
t = sierpinski n-1
freeze above t, beside t, t
sierpinski 8
Ракетная прога (без учёта "#lang racket") — короче на одну строку благодаря фиче вызова ф-ции вместе с определением. Размером же её код: 168 символов. Кофескриптовый код — 156.
Читабельность — разница налицо.
К слову, ракет — тоже мультипарадигмальный: «объектно-ориентированный, процедурный,
рефлективный, функциональный, логический, мета» (с педивикии).
Ну это всё мерянья одним место.
А главное: почему, если лисповые так уж хороши, то на них так… кхм… негусто софта?
Довольно громко поставлен вопрос, причём варианты ответа не взаимоисключающие (и профессионально можно работать за еду; причём, не только за еду).
мультипарадигмальный язык не позволяет вам по факту использовать ни одну парадигму в чистом виде.
Ну конечно же позволяет.
В своё время, изучая питон, я спокойно писал функционально и, грубо говоря, знать не знал оператор «class» и конструктор __init__. Через какое-то время дошёл до ООП и начал всё это применять.
Счас, на жабоскрипте, всё это возможно точно так же: кому не надо ООП — спокойно пишет ф-ции.
Ну, разве что, Вы сможете продемонстрировать случаи, где возможность писать в одной парадигме мешала бы пользовать другую.
Вы делаете прогноз на 10 лет, просто по текущему кол-ву открытых репозиториев на github? Ваше право, конечно, но имхо слабоватая метрика для прогнозов.
Метрика была написана: «Вобщем, основной тренд: асинхронность.» И указанные перед отсылом к гитхабу языки были выбраны именно по этому критерию.
JavaScript сейчас колбасит только так.
Ну если бурное развитие это «колбасит» — то пусть колбасит :)
С горизонтом 10 лет — бессмысленно.
Вышими же словами: «но имхо слабоватая метрика для прогнозов.». Это бессмысленно потому, что «колбасит»? Или почему бессмысленно?
Ну, ничего удивительного, синхронные языки уходят в прошлое (и питон в их числе, хоть последние версии и имеют async, но уже поздно).
А сотни ядер — это уже актуально, и 10 лет ждать незачем :)
Ну и если квантовые компутеры (это те, которые, якобы, не тратят время на вычисления?) шагнут в реальную жизнь — то всё равно у людей есть алгоритмы, которые будет нужно выполнять. Даже без затрат времени алгоритм не перестаёт быть алгоритмом. Чистая декларативность, как я понимаю, этого не обеспечивает?
Допустим для 0.5 она означает, что обе ветки и if и else исполняются равновероятно.
Ну да. А боле никаких данных то и нет. Только вот такое вот высказывание и возможно выжать.
Булева же логика может исполнить только одну ветку.
Строго говоря, булевая логика ничего не выполняет, она не описывает алгоритмы (но алгоритмами возможно описать последовательность вычисления состояния выражений булевой логики). Она описывает состояния.
Алгоритмы же — это пути перехода между состояниями.
И вот для условного алгоритма в точке развилки используется булевая логика для выяснения состояния условия и направления дальнейшего потока исполнения.
Если я Вас правильно понял, то
эмуляция вероятности через random — это введение новых искусственных данных в задачу. Но это, скорее, тестирование алгоритма, в котором участвует некая вероятность: правильно ли будет отрабатывать алгоритм при разных входных вероятностях (обычное unit-тестирование).
(очевидность mode) Да, вобщем, всё просто: время, отведённое виду хомо-сапиенс для детства — отведено не просто так, оно дано для подготовки ко взрослой жизни. (/очевидность mode) Следовательно, нужно давать самые актуальные вещи, которые востребованы во взрослой жизни.
Самые правильные фундаментальные знания, которые есть у человечества (хотя и заблуждения прошлого должны быть представлены в программе, но куда менее детально)
и самые востребованные технологии современности (но все былые технологии пересмотреть в программе — это вообще малореально), пусть они и изменятся к выпуску. К примеру, сейчас изучать работу компакт-дисков (в рамках курса технологий, а не фундамента) — всё-ж более адекватно, чем даже 3.5" дискеты.
то, на чём удобно демонстрировать чистые концепции, или то, где куча разнородных концепций перемешаны в дикую кашу. Вы за какой пункт из этих двух?
Я не могу назвать «кашей» мультипарадигмальный язык. Если на основе одного синтаксиса возможно показать больше концепций — то это явный выигрыш.
Про самообучение — да, дети ещё не умеют самообразовываться. Но если Вы таки доберётесь до «Закона Времени» — то поймёте, что если школа не научит самостоятельно учиться (а это нужно и показать, и рассказать, и активно практиковать, а затем и опираться на это в старших классах) — то это (вот, для наших дней и далее) будет самой большой ошибкой школы. И пока что, эта ошибка всё так же продолжается…
Постановка целей — предшествует созданию/изменению структур для их реализации (см. ПФУ из ДОТУ).
Так что, минобр может быть сколь угодно тормозным, но то, что нужно делать — можно определиться и не дожидаясь пока чиновники раздуплятся (ибо если не определиться — они вообще никогда не раздуплятся, будут просто бюджеты и дале пилить)
хоть и во втором эшелоне по популярности
Если есть возможность давать более востребованные знания новым поколениям… но нет, мы будет давать чуть похуже… Пусть те же индийские детки выглядять чуть лучше на фоне наших.
WAT???
список языков, которые Вы считаете перспективными с горизонтом 10 лет?
Первый эшелон: из семейства скриптовых: жабоскрипт (ну понятно) и всё, из низкоуровневых: Go (ибо с-подобный и асинхронный) и С.
Все остальные питоны, джавы, пхп, руби и т.д. — уже второй эшелон.
Да что тут считать. Берём статистику по языкам на гитхабе и всё видно (столбик слева):
https://github.com/search?o=desc&q=stars%3A%3E1&s=stars&type=Repositories
Впрочем, после выхода и стабилизации WebAssembly — монополия жабоскрипта пошатнётся (синтаксис у него всё-таки с-шный), рынок откусят более удобные синтаксисы, типа питоно-, рубе- или кофескриптово- подобные (хотя на кофях уже и счас можно писать).
Вобщем, основной тренд: асинхронность. Если она есть в самом языке (без необходимости сторонних либ) — то за ним будет и своя часть рынка.
Неужели нельзя на чём-то реально и массово востребованном на рынке нельзя объяснять?
Вы та боитесь конкуренции со стороны молодёжи, что предпочитаете их учить неактуальным вещам?
Компьютер как раз всегда исполняет чёткие алгоритмы, заложенные в него. Даже если сломан и «не включается» — то это всё равно исполнение алгоритмов, заложенных в него.
Человек, к слову, тоже всегда работает по алгоритмам. Другое дело откуда они взялись у него в голове.
В булевой логике нет понятия «вероятность».
Это просто вещественная переменная нужной точности.
А уж работать с переменными булевая логика может.
Про концепции речи нет. Их нужно изучать.
А на чём их практически пробывать во время учёбы?
На том, что реально нужно и работает, вот сейчас, или на том, что вышло из массового употребления лет 20 назад?
Но способ краткой записи всё равно нужен, так же как в математике.
А ещё, может, захочется дать детям посчупать комп на практике, и тут таки придётся пользоваться каким-то реальным ЯП. И выбор прост: брать что-то промышленное на данный момент (пусть оно и изменится через 5 лет) или брать то, что массово не востребовано в ромышленности?
давайте вообще школу отменим, можно же википедию почитать…
Вообще-то, дистанционные формы образования всё популярнее.
Или обязательно ходить в здание школы, чтоб там услышать унылую пестню педагога-пенсионера? (потому, что учителей-молодёжи за такую ЗП — негусто)
Только вот не читают, включая Вас,
Что будут читать школьники — вопрос организации и их мотивации.
А насчёт меня — я что, должен был Вам скопипастить оттуда сюда, чтобы показать, что я умею найти нужную мне в каждый момент времени информацию? :) самому не смешно?
судя по ответам на предыдущие вопросы :-)
Но что-то к моим ответам у Вас не появилось комментариев. Вы нигде не прокомментировали, если где что было неправильно.
Либо лень разбираться по сути, а не по копипасте из учебника, либо просто лень :) Впрочем, дело хозяйское.
Что за управление? Менеджеров хотите готовить?
Все люди всегда занимаются управлением. Кто-то управляет химическими реакциями (химики), кто-то физическими, кто-то предприятиями, кто-то общественными процессами и т.д.
И у управления как такового есть свои категории и закономерности. И если их знать — то войти в любую отрасль затем, после школы, в режиме самообразования, не составит большого труда. И именно это знание, знание теории управления, принадлежит к числу нетленных, не устаревающих со временем, что мегаважно в наш век перемен.
Ну, где вынуждены счас перебиваться учёные — примерно понятно: кто на рынке, кто в чём. Дурь «экономического» официоза заставляет раскорячиться.
Но спецязыки, которые не выходят за рамки школы — вот где проблема. Т.е. выходит такой себе микромир: ковыряется что-то для самого же микромира, а не для реального, куда выпускники таки выйдут в итоге.
Ну да это уже детали. Брать и просто не менять единожды созданное, или как-то самоограничиться с помощью средств языка. В итоге разницы практически нет.
Знал бы — зачем бы тогда спрашивал?
Потому и говорю, что нужно сравнивать экосистемы языков.
Наложить кучу… кхм… в голову людям, которые через 15-20 лет возьмут бразды правления страной в руки — сущие пустяки!
"- Так Вам нужна программа с применением ООП?
— Для тупых повторяю: рация сломалась на танке"
Но по факту мы не наблюдаем монополии какого-либо языка на всякую концепцию. Формирование обратного представления у детей — это гадить им в жизнь, своим детям и внукам, ну и себе в старости.
«Эх… на чём же писать-то?? ООП на сях или ООП на питоне??.. железа много — можно на питоне»
Примеры?
Где, кроме суровых железных ограничений, придётся пойти на «жёсткий компромисс» и выбрать моно-язык какой, без того же ООП, а оно в проекте нужно?
Почти все популярные языки нонче — мульти. Т.е. языка — это уже ф-ция от желания заказчика и наличия специалистов и даже немного :) от специфики задачи.
Если существующий проект — то боль и вопрос языка закрыт (разве что речь о «всё по-новой»).
Если проект новый/перепись — то выбор начинается.
Окинуть взором веб на предмет возможных вариантов/новинок/тенденций в ЯП (кстати, отдельными языками можно и нужно считать даже сторонние библиотеки, ибо это отдельный набор терминов и функционал).
Если долгосрочный — то важны затраты на поддержку: внесение изменений должно быть простым (быстрым и дешёвым) — нечто достаточно популярное и/ли с растущей популярностью (чтоб спецы на нём были по безоблачным ценам).
На этапе реализации основные затраты — это время людей. И они его не должны тратить на специфику специфичного чего-то без надобности. Т.е. приоритет тому, что уже знают (а знают, вероятнее всего — нечто популярное; а популярность в ЯП не падает с неба), либо то, что есть смысл изучить ввиду растущей популяpрности (проект то не последний).
Ну а дальше всё просто:
сервак/PC — где железа поболе — скриптовый ЯП высокого уровня (JS — фактически, уже без вариантов),
если железа мало/критичная скорость — то компилируемый язык: Go или С (ну максимум с асм вставками).
Если веб — ну совсем понятно (флеш или жаба-аплеты — уже всё).
Мобила — как и на десктопе (с поправкой, что низким уровнем может быть и андроидная жаба).
Ну а если какие ардуины многоногие — то там выбор не так широк.
Если ж нормальную ОСь там можно пустить («малинки» и ко) и по скорости/мозгам некритично — то можно сохранить время людей, взяв привычный ЯП высокого уровня (нода крутится на таком без вопросов).
Думаю, ни одному «гвоздю» мало не покажется.
Читабельность задаётся стереотипами, которые внедряются через образование. А это школа. А в школе — математика. И там оператор — между операндами.
Конечно же, это дело привычки. Но чем меньше информации нужно получить (и обработать) для понимания смысла — тем читабельность лучше.
Если не согласны — можем сравнить текст на С со скомпиленным бинарём в HEX'е ;)
Алгоритм один и тот же, но букаф — очень разное к-во.
Можно добавлять скобочек поначалу, пока появится привычка:
(последний вариант Вам должен понравиться ;) скобочек так, поболе)
Снова же дело привычки. Но есть потенциал роста скорости набора программы путём уменьшения объёма вводимой инфы (символов) при неизменной окончательной логике.
Собсно, это и есть смысл синтактического сахара как такового. Ну и, понятно, не все исторические языки затачивались под это.
Ну это вообще в стиле холивара «какой линух дистр лучше: с опенофисом по умолчанию или без». Так можно и какое-нить руби взять и померять пиписк*ми с ракетой или ещё чем.
Благо, на дворе не оффлайн 90-хх и дистр с языком друг принёс на компакте. Что надо — берётся и ставится.
И нужно сравнивать экосистемы языков. Ибо вот писать с нуля какую-нить либу — это вот уже боль.
Как я понимаю, каждую строчку исходников и качество кода ракет дистрибутива Вы лично проверяете перед использованием…
Тогда молчу :)
Ну, если у скрипта поменять шабанг — то тоже можно получить очень даже другой язык :)
Заведомо — неопределённо.
Равно равности двух случайных чисел.
Два разных вызова дадут разные случайные числа — потому в общем виде более точного ответа не дать.
Возможно. Но если из результата работы процедуры взять и получить результат — то это уже прям меняет парадигму программирования? Даже если — то что? :)
Вот я думаю, что ровно ничего. Наличие у подпрограммы входных и выходных параметров — это более общий случай отсутствия первых или вторых. Как бы это ни называлось.
Кому? %)
Получил значение выходного параметра — нужно записать в дневную отчётность: «воспользовался функциональной парадигмой»?
Вам шашечки или ехать?
Разогрет и буду благодарен за реальный пример.
Сам бы может и накопал чего, но «мутабельные данные» — это же просто переменные данные, ну а в память записать значение можно на очень многих языках. И ну не вижу почему это может мешать функциональному программированию.
Т.е. свежие ES6 и ES7, введшие множество фич и синтаксического сахара (движение к питон-стилю синтаксиса) — Вы не рассматриваете как развитие?
Просто хочу либо какой-то конкретики про JS (почему он так уж плох), либо простое «да пофиг на него просто».
Ну и на здоровье. Не улучшать что-то только для того, чтобы не менять… эээ? :)
Ну либо Вы в состоянии показать заведомо идеальный и давно неизменный ЯП?
Да, счас этого может уже быть и маловато. Но в той же ноде есть искаробки модуль для распараллеливания вширь. Нормальный такой костыль, пока ядро однопоточное (но всё же меняется… ;)
Вполне возможно, оно там как-то лучше завёрнуто (изначально в ТЗ на язык, видать, было так), но где тогда их распространённость?
На ерланге я знаю целую софтину (ejabberd) и либу распределённого хранения (кажись) mnesia…
Понятно, что маркетинг круче технического совершенства, но нода появилась не из-за маркетинга. Жабоскрипт сумел выйти из браузера в переполненную и чрезвычайно конкурентную среду серверного программирования (в виде ноды). В 2009. А сколько лет обозначенным языкам? Почему у них так негуст рынок при такой то архитектуре?
Вобщем, как я вижу: может по отдельным «концепциям» вполне возможно найти какие-то более удачные варианты, но суммарно по всем возможностям и экосистеме, которая на сегодня есть у жабоскрипта — вопрос о скриптовых языках закрыт надолго.
На каком ещё языке можно:
* писать асинхронно из коробки (без доп. либ)
* писать на всех (всех) мыслимых платформах: сервер, браузер, десктоп, мобил и даже всякие «малинки»
* иметь такую громадину готовых сторонних либ (более 200к либ только на npmjs, пусть даже не всё там для js, это с 2009; для сравнения: у синхронного питона на pypi около 70к либ, но с 1992 года(!!!)), и все эти либы — автоматически асинхронны, вопрос уместить в одном процессе разные сервера в принципе не стоит
Если можно — то, прошу, больше конкретики, без туманных терминов, типа «колбасит».
Если же просто неприятие жабосрипта (ещё год назад я плевался, примерно, как Вы счас) — то это тоже принимается. Никого к стенке прижимать я цели не имею, просто хочу узнать всякую конструктивную критику жабоскрипта и производных кофей (мне ж это в массы нести).
Ну и для эффективного использования 100 ядер нужно просто обеспечить беспроблемность в их совместной работе. Если имеют место общие данные — то нужна синхронизация (кстати неизменные переменные — это частный случай, когда запись в переменную вообще запрещена всегда; кстати, оператор const в других языках никто не отменял).
Так что только из-за иммутабельности выбирать для проекта (в том числе обучение) язык 3-го эшелона — неразумно. Объём сторонних библиотек и прочей инфы — всё это списать со счетов популярных языков только из-за одной фичи — не вариант. В том числе изучать редкий язык только из-за одной фичи для демонстрации одной из концепций — тоже не вариант. У учеников сложится впечатление, что «за ООП — это идти к ЯП1, функциональное — это к ЯП2, а эффективно использовать проц — это к ЯП3». Т.е. концепция демонстируется не сама со себе в таком случае, а вместе со всё новым языком. Наглядность улетучивается.
Вот это самый простой синтаксис??
это не смайлик, а 6 (ШЕСТЬ!!!) закрывающих скобочек.
C тут непричём. Копаем глубже. Где в жизни люди впервые применяют операторы сравнения меньше, больше и т.д.? — в школе.
И как они там выглядят? функциями «zero?» или «positive?»? — нет, математическим языком оно записывается знаками. Вполне логично и компьютеру писать программу такими же знаками (привычнее) и даже короче:
vs
И «zero? n» vs «n == 0» — 7 и 6 символов соотв.
Больше букв, к тому же нематематического синтаксиса.
Фракталы — это, конечно, просто отлично. Но рекурсия для этого есть не только в лиспах (впрочем, в ракете интересный подход, когда можно объявить ф-цию и тем же самым её вызвать: по сути, это скрытый оператор goto). Но синтаксис… просто жуть. Столько лишних (скобочек (в [самых] разных (местах)) ('просто?) кошмар)
Давайте прикинем. Кофескрипт. И для чистоты эксперимента буду пользовать либу с тем же именем и теми же ф-циями:
Ракетная прога (без учёта "#lang racket") — короче на одну строку благодаря фиче вызова ф-ции вместе с определением. Размером же её код: 168 символов. Кофескриптовый код — 156.
Читабельность — разница налицо.
К слову, ракет — тоже мультипарадигмальный: «объектно-ориентированный, процедурный,
рефлективный, функциональный, логический, мета» (с педивикии).
Ну это всё мерянья одним место.
А главное: почему, если лисповые так уж хороши, то на них так… кхм… негусто софта?
Ну конечно же позволяет.
В своё время, изучая питон, я спокойно писал функционально и, грубо говоря, знать не знал оператор «class» и конструктор __init__. Через какое-то время дошёл до ООП и начал всё это применять.
Счас, на жабоскрипте, всё это возможно точно так же: кому не надо ООП — спокойно пишет ф-ции.
Ну, разве что, Вы сможете продемонстрировать случаи, где возможность писать в одной парадигме мешала бы пользовать другую.
Метрика была написана: «Вобщем, основной тренд: асинхронность.» И указанные перед отсылом к гитхабу языки были выбраны именно по этому критерию.
Ну если бурное развитие это «колбасит» — то пусть колбасит :)
Вышими же словами: «но имхо слабоватая метрика для прогнозов.». Это бессмысленно потому, что «колбасит»? Или почему бессмысленно?
Да, coffeescript рулит.
А сотни ядер — это уже актуально, и 10 лет ждать незачем :)
Ну и если квантовые компутеры (это те, которые, якобы, не тратят время на вычисления?) шагнут в реальную жизнь — то всё равно у людей есть алгоритмы, которые будет нужно выполнять. Даже без затрат времени алгоритм не перестаёт быть алгоритмом. Чистая декларативность, как я понимаю, этого не обеспечивает?
Ну да. А боле никаких данных то и нет. Только вот такое вот высказывание и возможно выжать.
Строго говоря, булевая логика ничего не выполняет, она не описывает алгоритмы (но алгоритмами возможно описать последовательность вычисления состояния выражений булевой логики). Она описывает состояния.
Алгоритмы же — это пути перехода между состояниями.
И вот для условного алгоритма в точке развилки используется булевая логика для выяснения состояния условия и направления дальнейшего потока исполнения.
Если я Вас правильно понял, то
эмуляция вероятности через random — это введение новых искусственных данных в задачу. Но это, скорее, тестирование алгоритма, в котором участвует некая вероятность: правильно ли будет отрабатывать алгоритм при разных входных вероятностях (обычное unit-тестирование).
это ж наркомания %))))
(очевидность mode) Да, вобщем, всё просто: время, отведённое виду хомо-сапиенс для детства — отведено не просто так, оно дано для подготовки ко взрослой жизни. (/очевидность mode) Следовательно, нужно давать самые актуальные вещи, которые востребованы во взрослой жизни.
Самые правильные фундаментальные знания, которые есть у человечества (хотя и заблуждения прошлого должны быть представлены в программе, но куда менее детально)
и самые востребованные технологии современности (но все былые технологии пересмотреть в программе — это вообще малореально), пусть они и изменятся к выпуску. К примеру, сейчас изучать работу компакт-дисков (в рамках курса технологий, а не фундамента) — всё-ж более адекватно, чем даже 3.5" дискеты.
Я не могу назвать «кашей» мультипарадигмальный язык. Если на основе одного синтаксиса возможно показать больше концепций — то это явный выигрыш.
Про самообучение — да, дети ещё не умеют самообразовываться. Но если Вы таки доберётесь до «Закона Времени» — то поймёте, что если школа не научит самостоятельно учиться (а это нужно и показать, и рассказать, и активно практиковать, а затем и опираться на это в старших классах) — то это (вот, для наших дней и далее) будет самой большой ошибкой школы. И пока что, эта ошибка всё так же продолжается…
Спасибо за рекомендацию.
Так что, минобр может быть сколь угодно тормозным, но то, что нужно делать — можно определиться и не дожидаясь пока чиновники раздуплятся (ибо если не определиться — они вообще никогда не раздуплятся, будут просто бюджеты и дале пилить)
Если есть возможность давать более востребованные знания новым поколениям… но нет, мы будет давать чуть похуже… Пусть те же индийские детки выглядять чуть лучше на фоне наших.
WAT???
Первый эшелон: из семейства скриптовых: жабоскрипт (ну понятно) и всё, из низкоуровневых: Go (ибо с-подобный и асинхронный) и С.
Все остальные питоны, джавы, пхп, руби и т.д. — уже второй эшелон.
Да что тут считать. Берём статистику по языкам на гитхабе и всё видно (столбик слева):
https://github.com/search?o=desc&q=stars%3A%3E1&s=stars&type=Repositories
Впрочем, после выхода и стабилизации WebAssembly — монополия жабоскрипта пошатнётся (синтаксис у него всё-таки с-шный), рынок откусят более удобные синтаксисы, типа питоно-, рубе- или кофескриптово- подобные (хотя на кофях уже и счас можно писать).
Вобщем, основной тренд: асинхронность. Если она есть в самом языке (без необходимости сторонних либ) — то за ним будет и своя часть рынка.
Вы та боитесь конкуренции со стороны молодёжи, что предпочитаете их учить неактуальным вещам?
Человек, к слову, тоже всегда работает по алгоритмам. Другое дело откуда они взялись у него в голове.
Это просто вещественная переменная нужной точности.
А уж работать с переменными булевая логика может.
А на чём их практически пробывать во время учёбы?
На том, что реально нужно и работает, вот сейчас, или на том, что вышло из массового употребления лет 20 назад?
А ещё, может, захочется дать детям посчупать комп на практике, и тут таки придётся пользоваться каким-то реальным ЯП. И выбор прост: брать что-то промышленное на данный момент (пусть оно и изменится через 5 лет) или брать то, что массово не востребовано в ромышленности?
Вообще-то, дистанционные формы образования всё популярнее.
Или обязательно ходить в здание школы, чтоб там услышать унылую пестню педагога-пенсионера? (потому, что учителей-молодёжи за такую ЗП — негусто)
Что будут читать школьники — вопрос организации и их мотивации.
А насчёт меня — я что, должен был Вам скопипастить оттуда сюда, чтобы показать, что я умею найти нужную мне в каждый момент времени информацию? :) самому не смешно?
Но что-то к моим ответам у Вас не появилось комментариев. Вы нигде не прокомментировали, если где что было неправильно.
Либо лень разбираться по сути, а не по копипасте из учебника, либо просто лень :) Впрочем, дело хозяйское.
Все люди всегда занимаются управлением. Кто-то управляет химическими реакциями (химики), кто-то физическими, кто-то предприятиями, кто-то общественными процессами и т.д.
И у управления как такового есть свои категории и закономерности. И если их знать — то войти в любую отрасль затем, после школы, в режиме самообразования, не составит большого труда. И именно это знание, знание теории управления, принадлежит к числу нетленных, не устаревающих со временем, что мегаважно в наш век перемен.
Но спецязыки, которые не выходят за рамки школы — вот где проблема. Т.е. выходит такой себе микромир: ковыряется что-то для самого же микромира, а не для реального, куда выпускники таки выйдут в итоге.