Да и надо вообще типизацию объяснять, кто вам такую глупость сказал что нужно объяснять типизацию?
Прочитайте SICP, там в первых трех-четырех разделах проходится материал, эквивалентный году обучения в российском вузе. И там вообще нет типизации. Она неявно присутствует, но нигде не объясняется.
Потому уже, при создании интерпретатора вводятся метки типов и vtbl.
Объекты в JS и есть map. Значение в map может быть функцией.
Этого достаточно.
В таком случае подход со статической типизацией всего лишь делает явными все ваши неявные контракты на структуры данных (которые вы предлагаете держать в уме).
Подход со статической типизацией требует изучения системы типов, а это чуть ли не самое сложное в современных языках. Только некоторые ФЯ умудряются прятать сложность системы типов для потребителя, остальные, вроде java и C#, и тем более C++, вываливают эту сложность в самом начале.
Целью начального обучения не является изучение системы типов конкретного яызка. Поэтому динамические языки подходят гораздо лучше статически типизированных.
Я же писал что для начального обучения ООП нельзя. Во-первых поражает мозг, во-вторых банально сложная тема со всеми примочками, в третьих в разных языках сильно разное ООП, поэтому для изучения ООП нужно минимум два языка, а лучше три. В четвертых в небольших программах ООП только мешает.
Тебе понадобится много времени чтобы объяснить generics, а для этого тебе надо будет объяснить как работает типизация. Некоторые опытные программисты до сих пор не понимают это.
Ты все еще забываешь, что суть начального обучения не в том чтобы впихнуть как можно больше концепций в голову студента, и не в том чтобы научить его писать взрослые программы.
Важно дать понимание комбинированию, базовым структурам данных, алгоритмам, при этом как можно меньше загружать мозг лишними деталями.
Это переводит систему из разряда AP в CA. Тут возникает другая проблема, типичная для NoSQL.
И вот две «куда-то» потерялись. То есть остальные 8 их не видят. Часть приложения видит две ноды, часть видит 8.
Внимание вопрос — продавать билеты? Вариант поставить в очередь не катит, ибо человеку билет нужно напечтать. Откатить естественно тоже нельзя.
Если да, то где гарантия что не продадут два билета? Если нет, то на кой нам 10 шард и MongoDB вообще? Что делать если две ноды потерялись надолго (умерли машины)?
Предлагаю как раз не обобщать. Ибо любое обобщение скрывает детали, которые могут оказаться крайне важны.
По поводу кешей — все гораздо проще. Ибо если не валить все кеши в кучу, то очень легко разобраться когда и какой кеш нужен и как его инвалидировать.
Я уже писал что кеш нельзя просто включить, нужно думать головой. Кстати стратегия «сбросить кешь по ключу\тегу» при записи работает для среднего приложения всегда. Теги при этом управляются вызывающим кодом и не требуют обработки данных в кеше.
С чего бы это? JS легкий язык. В нем много тонкостей и тайных мест, но они не нужны чтобы писать программы. Вообще не нужны. Придерживаясь простых правил почти все грабли можно обойти.
У него много недостатков из-за типизации и модульности, но к обучению программированию это отношения не имеет.
А зачем объявлять переменную, которую не знаешь чем будешь инициализировать?
ЗЫ. Установка даже одного компонента для обучения — дофига, это сразу у 30% студентов отобьёт желание что-то делать. Кстати я как-то пробовал поставить Netbeans когда учился в универе — не взлетел.
Без Consistency современные РСУБД не имеют смысла, так как базовые гарантии, типа целостности внешних ключей, нельзя выполнить.
РСУБД на одной машине является CA, а на P насрать, его не бывает. В failover режиме БД становится почти CAP, но A и P нестрогие, то есть при некоторых условиях база становится недоступна. В зависимости от вероятности наступления таких условий и можно гарантировать заданный процент доступности при ACID гарантиях.
Но обычно это дорого, вернее ДОРОГО.
NoSQL предлагают дешевый способ организовать AP, теряя consistency (даже в случае acid гарантий записи).
Тут нужно понимать что C,A и P это не просто атрибут, который есть или нет. Нужно понимать в каких условиях достигаются эти параметры, а в каких нет.
Очень просто — partition ignorance называется. То есть если между узлами базы пропала связь, то почти все NoSQL базы этого не замечают, распадаясь на независимые части, синхронизируя данные после восстановления связи.
НО. Consistency от этого падает, в некоторых случаях до нуля. Например система по продаже билетов при разделении нод базы потенциально может продать два билета на одно и то же место. Никакая логика приложения не поможет избежать такого случая.
О денормализации нет смысла говорить пока никто не пытается разбираться со структурой денормализованных данных.
Я изучал разные NoSQL, некоторые приблизились по надежности к SQL, не потеряв удобства. Увы MongoDB не один из них, хотя де-факто это стандарт в мире NoSQL, на который равняются.
Что касается кешей и их инвалидации, то это называется тегами, в некоторых системах поддерживается явно, если не поддерживается явно, то можно прикрутить. Наличие тегов как раз позволяет не лезть внутрь закешированных данных.
Ну получается что надо:
1) хранить все джоины
2) вычислять джоины ркуками.
Джоинов в программе пропорционально количеству связей. А количество связей пропорционально квадрату количества сущностей.
Это повышает сложность разработки оооооооооооочень сильно. Прикрутить шардинг к любой SQL базе окажется гораздо легче. Это будет локальное одноразовое изменение.
Я еще не говорил про высоконагруженный проект. Вот например stackowerflow очень даже высоконагруженный, но они вполне допускают простои на час в неделю. Скорее всего как раз из-за накатывания изменений.
Кстати апдейт схемы проблема для MySQL, и вовсе не проблема для MSSQL, пока нету миллиардов записей.
Кеширование денормализованных данных и хранение денормализованных данных — две большие разницы. Денормализованные данные — фактически blob, как только вам становится важно что внутри — начинаются проблемы. Кеш обычно данные как есть отдает другому слою, не вникая. Разбираться в структуре кеша при записи не нужно, его можно просто пересобрать из storage.
Как раз целостность обеспечивается записью денормализованных документов. (просто кусков JSON). А вот гораздо интереснее становится когда важно что внутри этого JSON.
Классический пример для NoSQL — БД фильмов, которая хранит фильмы, ревью, комменты к ревью. Каждый фильм это документ, которых хранит все связанные данные. Вот проблемы начнутся тогда, когда надо будет показать все комменты одного автора. А эта задача может появится сильно после того как будет выбрана структура данных.
И это простой кейс, могут быть гораздо сложнее, которые и индексами не покроешь.
А если разнести по разным документам, то получает отсутствие джоинов и транзакций, и все проблемы с этим связанные.
Можно хранить несколько документов, один все по фильму содержит, второй все по автору. Но тогда запись будет происходить в N (>> 2 в реальной системе) документов, что медленно и нетразнакционно. А обрабатывать изменения связей становится очень геморройно.
1) Практика показывает что студенты в среднем редко дома ставят софт, кроме того современные IDE требуют мощных компов.
2) посмотри как работает jsfiddle
3) надо учить сразу инициализировать при объявлении, все остальное запретить, кстати JSHint показывает такие места, ну и 'use strict' обязательно. Не забывайте что при обучении код пишется в первую очередь для преподавателя, а потом для компьютера. Естественно преподаватель должен все проблемные места указать и потребовать исправить. В этом и суть обучения — тренировка писать правильный код на уровне моторных навыков.
4) Java, C# и C++ не подходят по причине необходимости установки тонны софта, необходимости знать и понимать систему типов и public-sttaic-void-main-overhead. В качестве языка для продолжения обучения (2 семестр или максимум 2-й год) C# и Java подойдут очень хорошо.
Прочитайте SICP, там в первых трех-четырех разделах проходится материал, эквивалентный году обучения в российском вузе. И там вообще нет типизации. Она неявно присутствует, но нигде не объясняется.
Потому уже, при создании интерпретатора вводятся метки типов и vtbl.
Этого достаточно.
Подход со статической типизацией требует изучения системы типов, а это чуть ли не самое сложное в современных языках. Только некоторые ФЯ умудряются прятать сложность системы типов для потребителя, остальные, вроде java и C#, и тем более C++, вываливают эту сложность в самом начале.
Целью начального обучения не является изучение системы типов конкретного яызка. Поэтому динамические языки подходят гораздо лучше статически типизированных.
Ты все еще забываешь, что суть начального обучения не в том чтобы впихнуть как можно больше концепций в голову студента, и не в том чтобы научить его писать взрослые программы.
Важно дать понимание комбинированию, базовым структурам данных, алгоритмам, при этом как можно меньше загружать мозг лишними деталями.
И вот две «куда-то» потерялись. То есть остальные 8 их не видят. Часть приложения видит две ноды, часть видит 8.
Внимание вопрос — продавать билеты? Вариант поставить в очередь не катит, ибо человеку билет нужно напечтать. Откатить естественно тоже нельзя.
Если да, то где гарантия что не продадут два билета? Если нет, то на кой нам 10 шард и MongoDB вообще? Что делать если две ноды потерялись надолго (умерли машины)?
По поводу кешей — все гораздо проще. Ибо если не валить все кеши в кучу, то очень легко разобраться когда и какой кеш нужен и как его инвалидировать.
Я уже писал что кеш нельзя просто включить, нужно думать головой. Кстати стратегия «сбросить кешь по ключу\тегу» при записи работает для среднего приложения всегда. Теги при этом управляются вызывающим кодом и не требуют обработки данных в кеше.
У него много недостатков из-за типизации и модульности, но к обучению программированию это отношения не имеет.
Важный аспект — не должно быть классов и, тем более, виртуальных функций.
ЗЫ. Установка даже одного компонента для обучения — дофига, это сразу у 30% студентов отобьёт желание что-то делать. Кстати я как-то пробовал поставить Netbeans когда учился в универе — не взлетел.
РСУБД на одной машине является CA, а на P насрать, его не бывает. В failover режиме БД становится почти CAP, но A и P нестрогие, то есть при некоторых условиях база становится недоступна. В зависимости от вероятности наступления таких условий и можно гарантировать заданный процент доступности при ACID гарантиях.
Но обычно это дорого, вернее ДОРОГО.
NoSQL предлагают дешевый способ организовать AP, теряя consistency (даже в случае acid гарантий записи).
Тут нужно понимать что C,A и P это не просто атрибут, который есть или нет. Нужно понимать в каких условиях достигаются эти параметры, а в каких нет.
НО. Consistency от этого падает, в некоторых случаях до нуля. Например система по продаже билетов при разделении нод базы потенциально может продать два билета на одно и то же место. Никакая логика приложения не поможет избежать такого случая.
Я изучал разные NoSQL, некоторые приблизились по надежности к SQL, не потеряв удобства. Увы MongoDB не один из них, хотя де-факто это стандарт в мире NoSQL, на который равняются.
Что касается кешей и их инвалидации, то это называется тегами, в некоторых системах поддерживается явно, если не поддерживается явно, то можно прикрутить. Наличие тегов как раз позволяет не лезть внутрь закешированных данных.
1) хранить все джоины
2) вычислять джоины ркуками.
Джоинов в программе пропорционально количеству связей. А количество связей пропорционально квадрату количества сущностей.
Это повышает сложность разработки оооооооооооочень сильно. Прикрутить шардинг к любой SQL базе окажется гораздо легче. Это будет локальное одноразовое изменение.
Кстати апдейт схемы проблема для MySQL, и вовсе не проблема для MSSQL, пока нету миллиардов записей.
Кеширование денормализованных данных и хранение денормализованных данных — две большие разницы. Денормализованные данные — фактически blob, как только вам становится важно что внутри — начинаются проблемы. Кеш обычно данные как есть отдает другому слою, не вникая. Разбираться в структуре кеша при записи не нужно, его можно просто пересобрать из storage.
Классический пример для NoSQL — БД фильмов, которая хранит фильмы, ревью, комменты к ревью. Каждый фильм это документ, которых хранит все связанные данные. Вот проблемы начнутся тогда, когда надо будет показать все комменты одного автора. А эта задача может появится сильно после того как будет выбрана структура данных.
И это простой кейс, могут быть гораздо сложнее, которые и индексами не покроешь.
А если разнести по разным документам, то получает отсутствие джоинов и транзакций, и все проблемы с этим связанные.
Можно хранить несколько документов, один все по фильму содержит, второй все по автору. Но тогда запись будет происходить в N (>> 2 в реальной системе) документов, что медленно и нетразнакционно. А обрабатывать изменения связей становится очень геморройно.
2) посмотри как работает jsfiddle
3) надо учить сразу инициализировать при объявлении, все остальное запретить, кстати JSHint показывает такие места, ну и 'use strict' обязательно. Не забывайте что при обучении код пишется в первую очередь для преподавателя, а потом для компьютера. Естественно преподаватель должен все проблемные места указать и потребовать исправить. В этом и суть обучения — тренировка писать правильный код на уровне моторных навыков.
4) Java, C# и C++ не подходят по причине необходимости установки тонны софта, необходимости знать и понимать систему типов и public-sttaic-void-main-overhead. В качестве языка для продолжения обучения (2 семестр или максимум 2-й год) C# и Java подойдут очень хорошо.
А в начальном обучении надо как можно меньше загружать мозг такими вещами.