Ну так по сути объект существует только с того момента, как он записан в БД
В общем случае это не так. К примеру, у нас могут быть и такие объекты, которые существуют временно, в каком-нибудь словаре, а решение об их сохранении в репозиторий может приниматься позднее. Разумеется, можно придумать и другие примеры.
Но вообще, даже если в нашей системе, для всех клиентов, каждый объект «существует» только если он уже записан в БД, то для самого сервера, это условие всё равно не выполняется. Для сервера, создание объекта и сохранение его в репозиторий — это две разные операции. Помимо них, он должен ещё много чего делать, например логирование, кэширование, ответ клиенту и т.д. Для каких-то операций может быть нужно, чтобы объект уже лежал в базе. Для других, достаточно, чтобы он просто был создан. А учитывая, что запись в БД гораздо медленнее создания объекта в памяти, то пренебрегать этим неразумно.
Серверу, как правило, удобнее предоставлять клиентам «оптимистичный» API. Зачем нам ждать запись объекта в базу, если можно сразу вернуть клиенту ответ. Вот только в этом ответе, клиенту уже нужен id.
Перекладывание задачи по генерации некоторых полей на СУБД, размазывает серверную логику, между приложением и СУБД. Изначально, автогенерация, а так же хранимые процедуры и триггеры были добавлены в СУБД, чтобы была возможность обходиться без серверного приложения. Роль серверного приложения, в таком случае, берёт на себя СУБД. Если же у нас есть сервис, который предоставляет Web API для доступа к данным, а все остальные работают через него, то необходимость во всех этих наворотах отпадает, и самым разумным решением будет свести их использование к минимуму, а то и вовсе отказаться от них, чтобы не размазывать логику. Иногда, правда, подразумевается, что помимо приложения, с БД будут работать и люди, напрямую. В этом случае, нет нужды смешивать интерфейс для людей и для программы. Приложение может иметь полный доступ к таблицам, а люди — пользоваться хранимыми процедурами, через которые будет реализован контроль доступа для них. Единственный необходимый компромисс, в случае, если люди имеют возможность вносить изменения в базу напрямую — контроль целостности придётся по максимуму вынести в СУБД.
Есть ещё один важный аспект. Если логика размазана между СУБД и приложением, например, часть полей генерируется в СУБД, это, по сути, привязывает нас к модели разработки Data First, ведь без базы данных наш сервис становится инвалидом. Если же всё генерируется в приложении, то это развязывает нам руки — тут уже применимы как Data First, так и Code First.
Ну и в конце концов, независимость приложения от БД упрощает его тестирование.
Наверняка есть и ещё нюансы. Это всё, что пока пришло в голову.
отсутствие монотонности может ощутимо негативно влиять на производительность
Монотонность зависит от типа ключа, а не от того, кто его генерирует, будь то СУБД, серверное приложение, или клиенты. Другое дело, что если генерировать ключи будут клиенты, то монотонности добиться сложнее. Но обсуждаемый в статье UUID v7 как раз и решает эту задачу, т.к. является последовательным.
Это был просто пример. Суть в том, что используя стандартный random, можно получить либо не очень надёжную, либо очень ненадёжную случайность, в зависимости от того, что используется в качестве зерна. При этом, в JS мы не контролируем, каким будет зерно у стандартного Math.random(). Как по мне, этого достаточно, чтобы не использовать Math.random() в тех ситуациях, когда нам нужна хоть сколько-то надёжная случайность. Генерация UUID — это, как раз, одна из таких ситуаций.
сбой системного времени с одновременным сбросом зерна ровно в то же самое состояние в котором оно было в тот самый момент времени, а это уже очень маловероятно.
Если в качестве зерна используется timestamp, то вероятность уже не такая маленькая.
зерно можно сделать очень близким к «истинно случайному», например, если собирать по одному биту из TSC после каждого syscall
Вот только в js, Math.random() не позволяет задать зерно самостоятельно. И как оно там должно быть реализовано внутри — стандарт, насколько мне известно, не уточняет.
на сервере идентификаторы UUIDv7 должны генериться непосредственно в СУБД.
Только если у нас вся логика написана на хранимых процедурах, и нет отдельного серверного приложения. Если же за логику отвечает отдельное приложение, а СУБД — только хранилище, то любые, автоматически генерируемые в СУБД значения (ключи, даты и т.д.) — это антипаттерн, т.к. без фактической вставки в БД, сервис не сможет получить значение этих полей, а значит он не может сам, без участия СУБД, сконструировать новый объект. Можно, конечно, заранее запросить у СУБД пул идентификаторов. Последнее имеет смысл, например, для целочисленных ключей, которые просто генерируются по порядку. Запрашивать их у СУБД приходится, чтобы гарантировать их уникальность. Но как раз для UUID'ов это бессмысленно — они и так достаточно уникальны. Собственно, в этом основной плюс UUID'ов, что мы генерируем идентификаторы там, где нам удобно, с точки зрения нашей архитектуры, в том числе, можем генерировать их децентрализовано.
А если серьёзно, космос это область, где всё до мелочей должно быть проработано до старта.
…
Поэтому можно много жаловаться как «криворукие инженеры» чего-то не доделали, но давайте объективно — как часто мы сами что-либо делаем с первого раза?
Прочитав ваш комментарий четыре раза, я так и не понял, всё должно быть проработано до старта, потому что это космос, или, всё таки, нельзя требовать успеха с первого раза, потому что инженеры тоже люди? У вас заключительное предложение противоречит остальному параграфу. Что вы, в итоге, сказать-то хотели?
У языка Pascal, эта проблема тоже присутствует. А вот у многих других, рассмотренных альтернатив, таких проблем, либо нет, либо они гораздо менее выражены. Впрочем, с точки зрения учёбы, это не самый важный минус. Не случайно, эта проблема была указана последней, в длинном списке. Может и не стоило здесь её упоминать. Учиться можно и на каком-то одном компиляторе. Просто вспомнился этот вездесущий system(«pause»), которым грешили многие преподаватели, и подумалось, что они на ровном месте найдут, как научить какой-нибудь платформозависимой, или компиляторозависимой фигне. Для Pascal эта проблема не так актуальна, просто за счёт того, что этот язык, на сегодняшний момент, можно считать, чисто учебным, и все эти «издержки обучения», не выйдут за пределы экосистемы Pascal, которая и так мертва.
Я перечислил те языки, которые знаю, и использовал на практике, хотя бы немного. Кроме Rust, к нему я пока только присматриваюсь. Но те концепции, что там есть, я, хотя бы, в целом, представляю, и понимаю.
Про Лисп я знаю не много. По большому счёту, лишь то, что это такой «мета» язык, в синтаксис которого заложен необходимый минимум, а всё остальное, реализуется на самом языке.
Основным недостатком, я вижу то, что этот подход (насколько я его понимаю), сильно отличается от мейнстрима. И разница тут гораздо более глубокая, чем отличия между C и Pascal, например. Но мне сложно судить, насколько Лисп, в целом, мог бы быть полезен, при изучении в школе, и какие с ним могут быть трудности, потому что я его никогда не щупал.
Далеко не все будут программистами по профессии, при этом уметь накидать простые скрипты для простой автоматизации может пригодиться гораздо большему числу людей.
Далеко не все будут математиками по профессии. Какая польза, большинству людей, от производных или пределов, например? Может не тратить на них время, а вместо этого научить высчитывать переплату по кредиту, или показать как оплачивать коммуналку в КВЦ? Но школьное образование должно закладывать фундамент, который поможет учиться дальше. Если в школе ограничиться базовой арифметикой, многие пути в жизни будут закрыты. В то же время, бытовые навыки тоже нужны, но они стоят отдельно. Учитывать надо обе потребности. Мы говорим о том, что стоит изучать на уроках информатики. А ставить единственным критерием пользу в быту — это про уроки труда или домоводства. Информатика, сегодня, включает две категории знаний: 1. теория, низкоуровневые, фундаментальные вещи, лежащие в основе всего; 2. практические навыки для работы с информационными технологиями. И даже в языках программирования эта двойственность проявляется. Какие-то близки к фундаментальным основам, другие — сосредоточены на решении прикладных задач. Именно поэтому я и предложил изучать 2 разных языка, относящихся к разным уровням абстракции. На мой взгляд, это не прихоть, а необходимость. Ведь это как два разных мира, и чтобы изучить их оба, надо изучать оба.
Ну и да, учить два языка одновременно — плохая затея. Время, понятно, плюс у многих в голове получится каша.
Не будет никакой каши. Наоборот, многое будет понятней. Во-первых, сам факт изучения двух разных языков, потребует грамотно составить программу обучения, отталкивающуюся от фундаментальных концепций, а заодно, давать нормальные объяснения, например, не «Всё есть объект», а «В ОО парадигме, все сущности, принято рассматривать как объекты». Во-вторых, ученик тоже будет мотивирован к пониманию именно фундаментальных концепций, как раз чтобы всё уложить в голове, в стройную систему. Когда ты видишь, что одно и то же, можно реализовать по разному, ты начинаешь задавать очень важный вопрос: «Почему здесь решили сделать именно так?» При изучении двух принципиально разных подходов, просто нет другого выхода, кроме как отталкиваться от фундаментальных понятий, отделяя их от деталей. Это касается как учителя, так и ученика.
от того что мы начнем читать детям другой более «современный» язык никто ничего не потеряет
Только если этот язык будет не хуже чем Pascal, именно с точки зрения изучения основ. Каждый язык надо рассматривать в этом контексте отдельно, и не факт, что популярные языки не будут уступать Pascal, для задачи обучения. Даже при том, что во многом они его обогнали, и для работы, они могут быть, объективно, лучше. Python — слишком много магии, динамическая типизация, сборщик мусора. Нет отдельного синтаксиса для объявления переменной (не отличается от повторного присваивания). Как по мне, не самые лучшие характеристики для первого языка. Добавим к этому ООП, со всей его сложностью, оправданность которой трудно показать на школьных задачах (а тут ещё и множественное наследование в придачу). Python хорошо подойдёт как второй язык, после школьного Pascal, например. Java/C# — очень много фичей для промышленного программирования, которые не нужны школьникам. Тут не просто какое-то там ООП, а гораздо больше всего. Особенно в C#, но и Java догоняет в последнее время. На самом деле, даже в ВУЗе я не видел задач, которые бы позволяли раскрыть потенциал таких языков. В итоге, мы все эти фичи изучали, а зачем они реально нужны, понимания не было. C++ — огромное количество сложных для понимания концепций, которых нет в других языках. Move семантика, шаблоны, SFINAE, множественное наследование, и проблема ужасного бриллианта, виртуальное наследование. СИ-шные указатели нервно курят в сторонке. Много легаси. Сложная, недружелюбная инфраструктура, в «хакерском» стиле. Извольте изучить CMake, чтобы что-то сложнее «Hello World» собирать. Куча компиляторов, не совместимых между собой. Школьникам всё это точно не нужно. А изучать C++ на 10% — не очень хорошая идея, как по мне. Уж лучше знать язык по проще, но знать его твёрдо. Особенно, если смотреть с прицелом на дальнейшее образование, ибо ВУЗовский преподаватель будет скорее рад наличию у всех студентов, чёткой, одинаковой базы, чем отрывочным знаниям, пусть и актуальным. В последнем случае, он как раз скажет знаменитое: «Забудьте, чему вас учили в школе» — и начнёт объяснять всё с нуля. Собственно, а какой у него ещё выбор? Без приведения к общему знаменателю, это задача не решается. JavaScript — неявная, слабая, динамическая типизация. Вездесущая асинхронность (не нужная сложность для новичка). Сложная, «хакерская» инфраструктура, с кучей препроцессоров, транспиляторов и прочего. Наличие легаси в базовом синтаксисе (var, «use strict», использование function как конструкторов). C — слабо типизированный и не безопасный. Много неопределённого поведения. Без указателей жить нельзя. Для массивов абстракция слабовата (её нет). Со строками всё не очень хорошо (их нет). Но если сравнивать с предыдущими вариантами, то это лучший кандидат, из-за своей простоты(не так много концепций в нём). Но всё же, чисто для обучения, Pascal подойдёт лучше, благодаря более мощной системе типов, более высокоуровневой концепции массивов, наличию строк, и тому что там можно жить без указателей. Любой специалист вам скажет, что на C не столько сложно научится кодить, сколько сложно научиться это делать правильно. А от плохого кода на C, будет больше вреда, чем пользы. PHP — почти все те же минусы что и у Python. В добавок, концепции веб сервера, проникшие в язык, типа POST, GET, код в перемешку с HTML — не очень хорошо, для первого языка. Go — сборщик мусора. А так, не плохой кандидат, благодаря своей простоте и строгости. Rust — может быть сложно. Концепций много. И синтаксис своеобразный. Но, возможно, оно того стоит.
Вообще, лично я бы всерьёз рассмотрел вариант, с одновременным изучением двух разных языков, по принципу, один высокоуровневый и со сборщиком мусора, а второй с ручным управлением памятью. Например, Python/C или Go/Rust, Python/Pascal. Высокоуровневый лучше выбирать с точки зрения будущей полезности, но не слишком сложный, т.к. время не резиновое, да и не стоит людей мучить, если они не собираются становиться профи. А тот, который с ручным управлением памятью, нужен только для изучения более низкоуровневого программирования и основ работы с памятью. Можно тот же Pascal оставить. У него есть свои плюсы, с точки зрения обучения, да и учителя его уже знают. Но можно и заменить на Rust или на C. Rust, наверное, по интереснее будет.
З.Ы. все «недостатки» языков указаны с точки зрения их влияния на процесс обучения, и не обязательно являются недостатками «в общем смысле». Понятно, что вопрос, во многом, холиварный. Но если есть идеи или возражения, хотелось бы, чтобы дискуссия оставалась в рамках контекста обучения новичков. В частности, мне кажется, что динамическая типизация крайне плохо подходит для этой задачи. При том, что у неё есть свои применения, где она удобна. А неявный синтаксис объявления переменных — вроде мелочь, но реально мешает объяснить такую важнейшую концепцию, как область видимости. Хотя, может это только у меня с объяснением такой простой вещи проблема возникла — я не являюсь преподавателем, и опыт обучения других людей у меня не богатый. Но, в целом, у меня сложилось мнение, что чем строже язык, тем лучше это для обучения. Новички, вообще, очень грешат тем, что стремятся заставить свою программу работать «хоть как-то», и не понимают, что правильная работа программы, в конкретном случае, не гарантирует правильной работы в общем случае. Строго типизированный язык и строгий компилятор, хотя бы немного, заставляют их думать в концепции «общего случая».
Полного ощущения, например, полета, даже на тренажере не получаешь, а уж за компом тем более.
Ну и сколько раз вам довелось управлять настоящим самолётом? Если всё же довелось, или, может, вы, хотя бы, теоретически углублялись в тему, подскажите, какова цена вопроса? Что надо сделать, сколько времени и денег потратить, чтобы получить «полное ощущение полёта»?
Я бы не был так уверен, что планету обязательно засекут за сотни лет до сближения с Землёй. Планеты не настолько просто обнаружить. Эриду открыли только в 2005 году. В Википедии написано, что по расчётам, исследовательский аппарат может долететь до неё за 25 лет. А если допустить, что некая планета прилетела к нам впервые, насколько актуальными будут косвенные методы обнаружения? Или тут останется только возможность прямого наблюдения, и всё сведётся к удаче — посмотреть в нужном направлении, в нужное время?
А последний вариант — это как раз случай Horizon: Zero Dawn
Во избежание путаницы, уточню, для читающих, что это относится к варианту про ИИ и инопланетян, который был последним, до того как я добавил мой «Upd». Неудачно получилось.
Столкновение с другой планетой.
В качестве бреда: вирус, который делает людей нежизнеспособными, в условиях ненулевой гравитации.
Ещё, в качестве бреда: кто-то разумный, превосходящий людей по военной мощи (инопланетяне, взбесившийся ИИ), поставил условие, убраться с планеты, иначе экстерминатус.
Upd: ещё пришло в голову. Увеличение гравитации на Земле, скажем в 15-20 раз.
Но это значит, что вы в него вложились, и обесценивать его через действия, которые снижают к нему доверие, вам невыгодно!
Вы переоцениваете степень «обесценивания» блокчейна от вмешательства бэйкера в чью-то транзакцию.
Во-первых, реакция людей будет зависеть не от факта вмешательства, а от того, насколько данное вмешательство кажется приемлемым большинству людей. К примеру, богатые люди объединятся в некую «финансовую комиссию», и будут решать, кого ограничить в обслуживании, а мотивировать будут тем, что «этот человек террорист, и вообще растлевает детишек». И это прокатит. Всегда прокатывает.
Во-вторых, если рассматривать ситуацию, когда у нас есть общепризнанный блокчейн, используемый как основная валюта, хотя бы в масштабах страны (а может и мира, чем чёрт не шутит), простому человеку некуда будет деваться. Вот так просто, форкнуть блокчейн, и придти в магазин со своей валютой, про которую никто не слышал? Не выйдет. Никто вам батон колбасы не продаст за ваши собственные «тугрики». Извольте пользоваться «блокларом», как все. Теоретически, форк, конечно, будет возможен. Но сложность реализации будет примерно равна сложности совершения революции в своей стране (а то и в мире, если чёрт всё же пошутит).
Ну и, в конце концов, никто не мешает брать не линейную зависимость от количества денег, а, скажем, логарифмическую.
Ну и, в конце концов, никто не мешает богатому человеку распределить свои бабки по множеству счетов, чтобы взять не размером своего счёта, а количеством счетов. Нормально работать будет только линейная зависимость. Использование любой, более пологой функции — профанация.
Зависимость прибыли за счёт комиссий от поставленных денег максимум линейная, но вас же не смущает, что если мы с вами придём в банк и сделаем вклад, но вы вложите в 10 раз больше, чем я, то и процентов вы получите в 10 раз больше, чем я?
Про рафинированный капитализм не скажу, но я вижу разницу в том, что деньги, положенные в банк, затем идут в экономику. Банк их инвестирует куда-то, чтобы заработать больше, чем тот процент, который он обещал вам. В простейшем случае, просто даёт кому-то кредит, под больший процент. И тогда уже тот, кто взял кредит, пускает деньги на ветер в дело. В любом случае, деньги не лежат мёртвым грузом. В случае же с PoS, деньги будут именно лежать мёртвым грузом, просто как «доказательство лояльности» блокчейну. Ну то есть понимаете, это как сравнивать электричество, потраченное на функционирование станков на заводе, и электричество, потраченное на майнинг.
почитайте на досуге про PoS
Говорит человек, всерьёз(?) предложивший использовать логарифмическую зависимость.
а Proof of Work вскоре будет заменён на Proof of Stake у того же эфира
Мне кажется, Proof of Stake поставит крест на будущем криптовалют. Они никогда не смогут заменить фиат, если будут работать на Proof of Stake. Во всяком случае, я не представляю, как может работать экономика, в условиях, когда деньги приносят прибыль, за счёт того, что просто лежат. Вся современная экономика строится на том, чтобы стимулировать людей тратить деньги, а не складировать их «под матрац».
Впрочем, учитывая что в Bitcoin изначально была заложена дефляция, вместо инфляции, я сомневаюсь, что Сатоши, действительно, планировал заменить им фиат. Это скорее похоже на намеренно заложенный изъян, подобно тому, как ГМО растения намеренно делают бесплодными, чтобы не убежали в дикую природу, и не стали там неконтролируемо размножаться. Таким образом, если крипта когда-либо и заменит фиат, это точно будет не биток, а что-то более современное, созданное с учётом выявленных проблем. Ну и как следствие, все эти ваши эфиры, и прочие поделки, наследующие фундаментальный изъян битка, можно закапывать. Спасибо, что поучаствовали в эксперименте.
Конкретно, криптовалюты — нет, хотя их ещё требуется доводить до ума. Майнинг, по модели proof of work — однозначно, да. Точнее, он приемлем на ранних этапах, как первая идея, позволяющая доказать концепцию децентрализованной валюты, но в долгосрочной перспективе — это тупиковый путь.
В общем случае это не так. К примеру, у нас могут быть и такие объекты, которые существуют временно, в каком-нибудь словаре, а решение об их сохранении в репозиторий может приниматься позднее. Разумеется, можно придумать и другие примеры.
Но вообще, даже если в нашей системе, для всех клиентов, каждый объект «существует» только если он уже записан в БД, то для самого сервера, это условие всё равно не выполняется. Для сервера, создание объекта и сохранение его в репозиторий — это две разные операции. Помимо них, он должен ещё много чего делать, например логирование, кэширование, ответ клиенту и т.д. Для каких-то операций может быть нужно, чтобы объект уже лежал в базе. Для других, достаточно, чтобы он просто был создан. А учитывая, что запись в БД гораздо медленнее создания объекта в памяти, то пренебрегать этим неразумно.
Серверу, как правило, удобнее предоставлять клиентам «оптимистичный» API. Зачем нам ждать запись объекта в базу, если можно сразу вернуть клиенту ответ. Вот только в этом ответе, клиенту уже нужен id.
Перекладывание задачи по генерации некоторых полей на СУБД, размазывает серверную логику, между приложением и СУБД. Изначально, автогенерация, а так же хранимые процедуры и триггеры были добавлены в СУБД, чтобы была возможность обходиться без серверного приложения. Роль серверного приложения, в таком случае, берёт на себя СУБД. Если же у нас есть сервис, который предоставляет Web API для доступа к данным, а все остальные работают через него, то необходимость во всех этих наворотах отпадает, и самым разумным решением будет свести их использование к минимуму, а то и вовсе отказаться от них, чтобы не размазывать логику. Иногда, правда, подразумевается, что помимо приложения, с БД будут работать и люди, напрямую. В этом случае, нет нужды смешивать интерфейс для людей и для программы. Приложение может иметь полный доступ к таблицам, а люди — пользоваться хранимыми процедурами, через которые будет реализован контроль доступа для них. Единственный необходимый компромисс, в случае, если люди имеют возможность вносить изменения в базу напрямую — контроль целостности придётся по максимуму вынести в СУБД.
Есть ещё один важный аспект. Если логика размазана между СУБД и приложением, например, часть полей генерируется в СУБД, это, по сути, привязывает нас к модели разработки Data First, ведь без базы данных наш сервис становится инвалидом. Если же всё генерируется в приложении, то это развязывает нам руки — тут уже применимы как Data First, так и Code First.
Ну и в конце концов, независимость приложения от БД упрощает его тестирование.
Наверняка есть и ещё нюансы. Это всё, что пока пришло в голову.
Монотонность зависит от типа ключа, а не от того, кто его генерирует, будь то СУБД, серверное приложение, или клиенты. Другое дело, что если генерировать ключи будут клиенты, то монотонности добиться сложнее. Но обсуждаемый в статье UUID v7 как раз и решает эту задачу, т.к. является последовательным.
Мне нужны твои разрешения, материалы, и
мотоциклоплата.Если в качестве зерна используется timestamp, то вероятность уже не такая маленькая.
Вот только в js, Math.random() не позволяет задать зерно самостоятельно. И как оно там должно быть реализовано внутри — стандарт, насколько мне известно, не уточняет.
Только если у нас вся логика написана на хранимых процедурах, и нет отдельного серверного приложения. Если же за логику отвечает отдельное приложение, а СУБД — только хранилище, то любые, автоматически генерируемые в СУБД значения (ключи, даты и т.д.) — это антипаттерн, т.к. без фактической вставки в БД, сервис не сможет получить значение этих полей, а значит он не может сам, без участия СУБД, сконструировать новый объект. Можно, конечно, заранее запросить у СУБД пул идентификаторов. Последнее имеет смысл, например, для целочисленных ключей, которые просто генерируются по порядку. Запрашивать их у СУБД приходится, чтобы гарантировать их уникальность. Но как раз для UUID'ов это бессмысленно — они и так достаточно уникальны. Собственно, в этом основной плюс UUID'ов, что мы генерируем идентификаторы там, где нам удобно, с точки зрения нашей архитектуры, в том числе, можем генерировать их децентрализовано.
…
Прочитав ваш комментарий четыре раза, я так и не понял, всё должно быть проработано до старта, потому что это космос, или, всё таки, нельзя требовать успеха с первого раза, потому что инженеры тоже люди? У вас заключительное предложение противоречит остальному параграфу. Что вы, в итоге, сказать-то хотели?
Тем временем, голосовые сообщения существуют.
Я перечислил те языки, которые знаю, и использовал на практике, хотя бы немного. Кроме Rust, к нему я пока только присматриваюсь. Но те концепции, что там есть, я, хотя бы, в целом, представляю, и понимаю.
Про Лисп я знаю не много. По большому счёту, лишь то, что это такой «мета» язык, в синтаксис которого заложен необходимый минимум, а всё остальное, реализуется на самом языке.
Основным недостатком, я вижу то, что этот подход (насколько я его понимаю), сильно отличается от мейнстрима. И разница тут гораздо более глубокая, чем отличия между C и Pascal, например. Но мне сложно судить, насколько Лисп, в целом, мог бы быть полезен, при изучении в школе, и какие с ним могут быть трудности, потому что я его никогда не щупал.
Далеко не все будут математиками по профессии. Какая польза, большинству людей, от производных или пределов, например? Может не тратить на них время, а вместо этого научить высчитывать переплату по кредиту, или показать как оплачивать коммуналку в КВЦ? Но школьное образование должно закладывать фундамент, который поможет учиться дальше. Если в школе ограничиться базовой арифметикой, многие пути в жизни будут закрыты. В то же время, бытовые навыки тоже нужны, но они стоят отдельно. Учитывать надо обе потребности. Мы говорим о том, что стоит изучать на уроках информатики. А ставить единственным критерием пользу в быту — это про уроки труда или домоводства. Информатика, сегодня, включает две категории знаний: 1. теория, низкоуровневые, фундаментальные вещи, лежащие в основе всего; 2. практические навыки для работы с информационными технологиями. И даже в языках программирования эта двойственность проявляется. Какие-то близки к фундаментальным основам, другие — сосредоточены на решении прикладных задач. Именно поэтому я и предложил изучать 2 разных языка, относящихся к разным уровням абстракции. На мой взгляд, это не прихоть, а необходимость. Ведь это как два разных мира, и чтобы изучить их оба, надо изучать оба.
Не будет никакой каши. Наоборот, многое будет понятней. Во-первых, сам факт изучения двух разных языков, потребует грамотно составить программу обучения, отталкивающуюся от фундаментальных концепций, а заодно, давать нормальные объяснения, например, не «Всё есть объект», а «В ОО парадигме, все сущности, принято рассматривать как объекты». Во-вторых, ученик тоже будет мотивирован к пониманию именно фундаментальных концепций, как раз чтобы всё уложить в голове, в стройную систему. Когда ты видишь, что одно и то же, можно реализовать по разному, ты начинаешь задавать очень важный вопрос: «Почему здесь решили сделать именно так?» При изучении двух принципиально разных подходов, просто нет другого выхода, кроме как отталкиваться от фундаментальных понятий, отделяя их от деталей. Это касается как учителя, так и ученика.
Только если этот язык будет не хуже чем Pascal, именно с точки зрения изучения основ. Каждый язык надо рассматривать в этом контексте отдельно, и не факт, что популярные языки не будут уступать Pascal, для задачи обучения. Даже при том, что во многом они его обогнали, и для работы, они могут быть, объективно, лучше.
Python — слишком много магии, динамическая типизация, сборщик мусора. Нет отдельного синтаксиса для объявления переменной (не отличается от повторного присваивания). Как по мне, не самые лучшие характеристики для первого языка. Добавим к этому ООП, со всей его сложностью, оправданность которой трудно показать на школьных задачах (а тут ещё и множественное наследование в придачу). Python хорошо подойдёт как второй язык, после школьного Pascal, например.
Java/C# — очень много фичей для промышленного программирования, которые не нужны школьникам. Тут не просто какое-то там ООП, а гораздо больше всего. Особенно в C#, но и Java догоняет в последнее время. На самом деле, даже в ВУЗе я не видел задач, которые бы позволяли раскрыть потенциал таких языков. В итоге, мы все эти фичи изучали, а зачем они реально нужны, понимания не было.
C++ — огромное количество сложных для понимания концепций, которых нет в других языках. Move семантика, шаблоны, SFINAE, множественное наследование, и проблема ужасного бриллианта, виртуальное наследование. СИ-шные указатели нервно курят в сторонке. Много легаси. Сложная, недружелюбная инфраструктура, в «хакерском» стиле. Извольте изучить CMake, чтобы что-то сложнее «Hello World» собирать. Куча компиляторов, не совместимых между собой. Школьникам всё это точно не нужно. А изучать C++ на 10% — не очень хорошая идея, как по мне. Уж лучше знать язык по проще, но знать его твёрдо. Особенно, если смотреть с прицелом на дальнейшее образование, ибо ВУЗовский преподаватель будет скорее рад наличию у всех студентов, чёткой, одинаковой базы, чем отрывочным знаниям, пусть и актуальным. В последнем случае, он как раз скажет знаменитое: «Забудьте, чему вас учили в школе» — и начнёт объяснять всё с нуля. Собственно, а какой у него ещё выбор? Без приведения к общему знаменателю, это задача не решается.
JavaScript — неявная, слабая, динамическая типизация. Вездесущая асинхронность (не нужная сложность для новичка). Сложная, «хакерская» инфраструктура, с кучей препроцессоров, транспиляторов и прочего. Наличие легаси в базовом синтаксисе (var, «use strict», использование function как конструкторов).
C — слабо типизированный и не безопасный. Много неопределённого поведения. Без указателей жить нельзя. Для массивов абстракция слабовата (её нет). Со строками всё не очень хорошо (их нет). Но если сравнивать с предыдущими вариантами, то это лучший кандидат, из-за своей простоты(не так много концепций в нём). Но всё же, чисто для обучения, Pascal подойдёт лучше, благодаря более мощной системе типов, более высокоуровневой концепции массивов, наличию строк, и тому что там можно жить без указателей. Любой специалист вам скажет, что на C не столько сложно научится кодить, сколько сложно научиться это делать правильно. А от плохого кода на C, будет больше вреда, чем пользы.
PHP — почти все те же минусы что и у Python. В добавок, концепции веб сервера, проникшие в язык, типа POST, GET, код в перемешку с HTML — не очень хорошо, для первого языка.
Go — сборщик мусора. А так, не плохой кандидат, благодаря своей простоте и строгости.
Rust — может быть сложно. Концепций много. И синтаксис своеобразный. Но, возможно, оно того стоит.
Вообще, лично я бы всерьёз рассмотрел вариант, с одновременным изучением двух разных языков, по принципу, один высокоуровневый и со сборщиком мусора, а второй с ручным управлением памятью. Например, Python/C или Go/Rust, Python/Pascal. Высокоуровневый лучше выбирать с точки зрения будущей полезности, но не слишком сложный, т.к. время не резиновое, да и не стоит людей мучить, если они не собираются становиться профи. А тот, который с ручным управлением памятью, нужен только для изучения более низкоуровневого программирования и основ работы с памятью. Можно тот же Pascal оставить. У него есть свои плюсы, с точки зрения обучения, да и учителя его уже знают. Но можно и заменить на Rust или на C. Rust, наверное, по интереснее будет.
З.Ы. все «недостатки» языков указаны с точки зрения их влияния на процесс обучения, и не обязательно являются недостатками «в общем смысле». Понятно, что вопрос, во многом, холиварный. Но если есть идеи или возражения, хотелось бы, чтобы дискуссия оставалась в рамках контекста обучения новичков. В частности, мне кажется, что динамическая типизация крайне плохо подходит для этой задачи. При том, что у неё есть свои применения, где она удобна. А неявный синтаксис объявления переменных — вроде мелочь, но реально мешает объяснить такую важнейшую концепцию, как область видимости. Хотя, может это только у меня с объяснением такой простой вещи проблема возникла — я не являюсь преподавателем, и опыт обучения других людей у меня не богатый. Но, в целом, у меня сложилось мнение, что чем строже язык, тем лучше это для обучения. Новички, вообще, очень грешат тем, что стремятся заставить свою программу работать «хоть как-то», и не понимают, что правильная работа программы, в конкретном случае, не гарантирует правильной работы в общем случае. Строго типизированный язык и строгий компилятор, хотя бы немного, заставляют их думать в концепции «общего случая».
Ну и сколько раз вам довелось управлять настоящим самолётом? Если всё же довелось, или, может, вы, хотя бы, теоретически углублялись в тему, подскажите, какова цена вопроса? Что надо сделать, сколько времени и денег потратить, чтобы получить «полное ощущение полёта»?
Во избежание путаницы, уточню, для читающих, что это относится к варианту про ИИ и инопланетян, который был последним, до того как я добавил мой «Upd». Неудачно получилось.
В качестве бреда: вирус, который делает людей нежизнеспособными, в условиях ненулевой гравитации.
Ещё, в качестве бреда: кто-то разумный, превосходящий людей по военной мощи (инопланетяне, взбесившийся ИИ), поставил условие, убраться с планеты, иначе экстерминатус.
Upd: ещё пришло в голову. Увеличение гравитации на Земле, скажем в 15-20 раз.
Вы переоцениваете степень «обесценивания» блокчейна от вмешательства бэйкера в чью-то транзакцию.
Во-первых, реакция людей будет зависеть не от факта вмешательства, а от того, насколько данное вмешательство кажется приемлемым большинству людей. К примеру, богатые люди объединятся в некую «финансовую комиссию», и будут решать, кого ограничить в обслуживании, а мотивировать будут тем, что «этот человек террорист, и вообще растлевает детишек». И это прокатит. Всегда прокатывает.
Во-вторых, если рассматривать ситуацию, когда у нас есть общепризнанный блокчейн, используемый как основная валюта, хотя бы в масштабах страны (а может и мира, чем чёрт не шутит), простому человеку некуда будет деваться. Вот так просто, форкнуть блокчейн, и придти в магазин со своей валютой, про которую никто не слышал? Не выйдет. Никто вам батон колбасы не продаст за ваши собственные «тугрики». Извольте пользоваться «блокларом», как все. Теоретически, форк, конечно, будет возможен. Но сложность реализации будет примерно равна сложности совершения революции в своей стране (а то и в мире, если чёрт всё же пошутит).
Ну и, в конце концов, никто не мешает богатому человеку распределить свои бабки по множеству счетов, чтобы взять не размером своего счёта, а количеством счетов. Нормально работать будет только линейная зависимость. Использование любой, более пологой функции — профанация.
Про рафинированный капитализм не скажу, но я вижу разницу в том, что деньги, положенные в банк, затем идут в экономику. Банк их инвестирует куда-то, чтобы заработать больше, чем тот процент, который он обещал вам. В простейшем случае, просто даёт кому-то кредит, под больший процент. И тогда уже тот, кто взял кредит, пускает деньги
на ветерв дело. В любом случае, деньги не лежат мёртвым грузом. В случае же с PoS, деньги будут именно лежать мёртвым грузом, просто как «доказательство лояльности» блокчейну. Ну то есть понимаете, это как сравнивать электричество, потраченное на функционирование станков на заводе, и электричество, потраченное на майнинг.Говорит человек, всерьёз(?) предложивший использовать логарифмическую зависимость.
Пластмассы тоже будут делать из ветра?
Мне кажется, Proof of Stake поставит крест на будущем криптовалют. Они никогда не смогут заменить фиат, если будут работать на Proof of Stake. Во всяком случае, я не представляю, как может работать экономика, в условиях, когда деньги приносят прибыль, за счёт того, что просто лежат. Вся современная экономика строится на том, чтобы стимулировать людей тратить деньги, а не складировать их «под матрац».
Впрочем, учитывая что в Bitcoin изначально была заложена дефляция, вместо инфляции, я сомневаюсь, что Сатоши, действительно, планировал заменить им фиат. Это скорее похоже на намеренно заложенный изъян, подобно тому, как ГМО растения намеренно делают бесплодными, чтобы не убежали в дикую природу, и не стали там неконтролируемо размножаться. Таким образом, если крипта когда-либо и заменит фиат, это точно будет не биток, а что-то более современное, созданное с учётом выявленных проблем. Ну и как следствие, все эти ваши эфиры, и прочие поделки, наследующие фундаментальный изъян битка, можно закапывать. Спасибо, что поучаствовали в эксперименте.
Конкретно, криптовалюты — нет, хотя их ещё требуется доводить до ума. Майнинг, по модели proof of work — однозначно, да. Точнее, он приемлем на ранних этапах, как первая идея, позволяющая доказать концепцию децентрализованной валюты, но в долгосрочной перспективе — это тупиковый путь.