Да, в функциональщине нужно долго и нудно запоминать приоритеты всех видов конструкций. В том числе поэтому они не рекомендуются для массового использования.
Либо это идрис «не торт», либо данная конструкция никогда не остановится. Первый элемент списка вечно ставится в конец, после чего весь список кидается на вход функции, которая опять первый элемент ставит последним, и так до тепловой смерти вселенной.
Да, зря тесты не были запущены. И да, формально — задание не выполнено. А неформально — не выполнено со страшно умным видом.
Вы же сами знаете — может. Так зачем упираться в стенку?
В плане очевиднейшего возражения «у него выйдет сложнее» — вы опять сами знаете, что ему на это плевать, ведь главное — он может, а ваш вопрос опять становится глупым.
При выборе языка не столь важны фичи, это выбор бизнеса, а потому все споры о таком выборе — попытка убедить бизнес в важности своих личных хотелок. Но хотелки субъективны по определению. Поэтому и ваше заявление выглядит бессмысленным, ведь оно точно так же субъективно и не интересно тем же гуглам, которым нужны дешёвые индусы, которым нужны простые языки. И пока вы будете исходить из своих хотелок — так ничего и не поймёте.
Чем отличается вектор-аргумент от вектора-параметра? Если не до конца понятно, то добавлю — аргумент и параметр — синонимы, что делает масло масляным (а названия — бессмысленными).
Определитель — это число. То есть в вашей формуле имеет место деление двух чисел, с получением на выходе, очевидно, тоже числа. При этом в самом начале речь идёт о векторах. Отсюда вывод — надо пояснять детали.
Математики вообще не склонны к обсуждению деталей, мол умный студент всё сам за них додумает, но это неправильно, это убивает интерес у тех, кто видит несколько вариантов объяснения деталей, ну а городить свою теорию вокруг каждого варианта — нет времени. При этом все мы знаем, что правильный вариант — один, поэтому огород вокруг всех остальных вариантов — часто просто банальное (и безжалостное) убийство времени изучающего по вине преподавателя. И да, обучающихся много, в сумме они убивают гигантское время, а всё потому, что преподавателю лень расписывать детали (на что требуется минимальное время).
Так что будьте внимательны к деталям, не ленитесь повторять всё то, что вам самому кажется очевидным, и даже то, о чём вы уже написали, потому что к моменту чтения следующей темы читатель часто забывает почти всё о предыдущей.
Аналогия с компьютером — он не будет работать, если вы ему не объясните всё до мелочей. А вот студент умнее, да, он иногда будет работать без объяснения мелочей, только все остальные сразу убегут от вашего предмета, да и умные убьют гораздо больше времени на обучение.
Хотя само желание что-то пояснить популярно — приветствуется.
В плане «быстрее» — у вас больше джойнов. При этом физическая реализация может оптимизировать джойны, но тогда ухудшается что-то другое, например внесение изменений.
То есть статья показывает пример улучшения простой ситуации при помощи автоматизации доступными средствами.
Но эффект типа «опыт я оцениваю как успешный» — это не совсем корректная оценка. Обычно выделяют некие метрики и следят за их улучшением. Без них результат внедрения оценивается лишь качественно. Хотя если затраты были небольшие, то и больших результатов тоже ждать не стоит.
Такое поветрие формируется намеренно, сначала юные архитекторы убеждают боссов использовать новый подход, потом выясняется, что специалистов по нему нет и большие конторы начинают вкладываться в популяризацию подхода. В итоге стихийно порождается много шума, но обоснованность всего этого зоопарка покоится, по сути, на мнении одного единственного экспериментатора — того самого архитектора, или просто человека с возможностями влиять на (часто случайный) выбор во внутренней кухне корпорации.
Хотя аналогия с модой, безусловно, есть. Но популяризируют продукт именно деньги корпораций, и лишь потому, что в их конкретной обстановке был выбран конкретный продукт. То есть бежать за этой «модой» — неэффективно, ибо выбор не основан на чём-то рациональном.
Среди людей принято увлекаться чем-либо, от религии до чайной церемонии, но религию обычно не называют модой, поэтому и выбор СУБД (и технологий вообще) — то же увлечение, которое даже может остаться на всю жизнь. Хотя если нравится, можно и модой обозвать :)
>> чем вываливать на студента ворох терминов в надежде, что он в них не захлебнется.
А с чего вы взяли, что я предлагаю вываливать ворох терминов? Я предлагаю не делать из людей идиотов попыткой убедить их в том, что они якобы с пользой отсидели в институтах 5 лет. И ворох терминов — один из вариантов получения идиотов на выходе. Только без понимания абстракций куча простеньких примеров точно так же делает из человека необразованного болванчика. Поэтому правильно учить людей «посередине», без вороха терминов, но и без потакания лени, когда ей не хочется учить абстракции.
>> Пунктуационные ошибки и опечатки не позволяют написать «носитель»
Вы видимо не видели некоторых настоящих «носителей», которые… Ну в общем их и видеть не стоит :)
Ошибки и опечатки, скорее, не позволяют утверждать, что вам стоит работать учителем русского языка в РФ, ну а всё остальное — на уровне, который много выше некоторых реальных «носителей», которые из всех видов русского языка знают только матерный :)
>> Мне не хотелось бы сваливаться в комментариях в дискуссии
И мне туда же.
Но джойны в РСУБД ликвидируются просто (если нужно), а вот реляционная модель со всеми удобствами в нереляционных базах нереализуема (ибо очень дорого). В сумме РСУБД может не хуже NoSQL, а NoSQL не может как РСУБД.
Есть отдельные узкие ниши, где отказ от РСУБД может ускорить некоторые виды обработки данных, но ускорение получается так себе (хотя может кому-то важно хотя бы 20-40% роста в обмен на отказ от всем привычного и гибкого). А в плане удобства работы с документами — просто используем приличный ORM и опять NoSQL становится ненужным.
Но да, я не спора ради, я пробую простую идею донести — в массовом применении РСУБД объективно лучше, а массовая популяризация NoSQL ради каких-то узких ниш — совершенно не оправдана.
Я бы назвал те древние подходы файло-ориентированными. Хотя не исключаю, что где-то в тёмных и мрачных пещерах с очень умными неандертальцами проскакивал шаблон хранения структурированных данных, но не на основе реляционной модели. Только это было исключением. Массово же — файлы. Да ещё с микроскопической скоростью обработки и на ленточных носителях…
Технически компилятор или среда исполнения могут начать с преобразования, но это не значит, что здесь нет проверки на тип данных. Потому что проверка — логическая. То есть программист мог попробовать распасить строку и ожидает получить либо эксепшн, либо число — вот это и есть логическая проверка, которую вы проигнорировали от отсутствия опыта. Ну а «когда мы кастим» — это уже не логическая, а чисто техническая реализация алгоритма проверки соответствия узким техническим возможностям (а не высокоуровневое выявления истинного типа).
Заголовок можно было подать так — ученые вырастили ткани со вживленной в них электроникой.
Либо это идрис «не торт», либо данная конструкция никогда не остановится. Первый элемент списка вечно ставится в конец, после чего весь список кидается на вход функции, которая опять первый элемент ставит последним, и так до тепловой смерти вселенной.
Да, зря тесты не были запущены. И да, формально — задание не выполнено. А неформально — не выполнено со страшно умным видом.
Так фортран всё ещё живой — осваивайте, программируйте.
Хотя проблема, конечно, важная. Но решить её вы не сможете никаким изобретением, потому что она — организационная.
Вы же сами знаете — может. Так зачем упираться в стенку?
В плане очевиднейшего возражения «у него выйдет сложнее» — вы опять сами знаете, что ему на это плевать, ведь главное — он может, а ваш вопрос опять становится глупым.
При выборе языка не столь важны фичи, это выбор бизнеса, а потому все споры о таком выборе — попытка убедить бизнес в важности своих личных хотелок. Но хотелки субъективны по определению. Поэтому и ваше заявление выглядит бессмысленным, ведь оно точно так же субъективно и не интересно тем же гуглам, которым нужны дешёвые индусы, которым нужны простые языки. И пока вы будете исходить из своих хотелок — так ничего и не поймёте.
Определитель — это число. То есть в вашей формуле имеет место деление двух чисел, с получением на выходе, очевидно, тоже числа. При этом в самом начале речь идёт о векторах. Отсюда вывод — надо пояснять детали.
Математики вообще не склонны к обсуждению деталей, мол умный студент всё сам за них додумает, но это неправильно, это убивает интерес у тех, кто видит несколько вариантов объяснения деталей, ну а городить свою теорию вокруг каждого варианта — нет времени. При этом все мы знаем, что правильный вариант — один, поэтому огород вокруг всех остальных вариантов — часто просто банальное (и безжалостное) убийство времени изучающего по вине преподавателя. И да, обучающихся много, в сумме они убивают гигантское время, а всё потому, что преподавателю лень расписывать детали (на что требуется минимальное время).
Так что будьте внимательны к деталям, не ленитесь повторять всё то, что вам самому кажется очевидным, и даже то, о чём вы уже написали, потому что к моменту чтения следующей темы читатель часто забывает почти всё о предыдущей.
Аналогия с компьютером — он не будет работать, если вы ему не объясните всё до мелочей. А вот студент умнее, да, он иногда будет работать без объяснения мелочей, только все остальные сразу убегут от вашего предмета, да и умные убьют гораздо больше времени на обучение.
Хотя само желание что-то пояснить популярно — приветствуется.
Ни в коем случае. Вахтёров нанимает большой дегенерат.
Как может нанятый за копейки полуграмотный индус понять обоснование алгоритма?
Я говорил про «повышение уровня абстракции».
Но эффект типа «опыт я оцениваю как успешный» — это не совсем корректная оценка. Обычно выделяют некие метрики и следят за их улучшением. Без них результат внедрения оценивается лишь качественно. Хотя если затраты были небольшие, то и больших результатов тоже ждать не стоит.
Это называется — повышение уровня абстракции. Оно полезно. Поэтому так доходить — можно.
Переведите разработку инфосистем на графы, тогда их область применимости станет более подходящей.
Хотя аналогия с модой, безусловно, есть. Но популяризируют продукт именно деньги корпораций, и лишь потому, что в их конкретной обстановке был выбран конкретный продукт. То есть бежать за этой «модой» — неэффективно, ибо выбор не основан на чём-то рациональном.
Среди людей принято увлекаться чем-либо, от религии до чайной церемонии, но религию обычно не называют модой, поэтому и выбор СУБД (и технологий вообще) — то же увлечение, которое даже может остаться на всю жизнь. Хотя если нравится, можно и модой обозвать :)
А с чего вы взяли, что я предлагаю вываливать ворох терминов? Я предлагаю не делать из людей идиотов попыткой убедить их в том, что они якобы с пользой отсидели в институтах 5 лет. И ворох терминов — один из вариантов получения идиотов на выходе. Только без понимания абстракций куча простеньких примеров точно так же делает из человека необразованного болванчика. Поэтому правильно учить людей «посередине», без вороха терминов, но и без потакания лени, когда ей не хочется учить абстракции.
Вы видимо не видели некоторых настоящих «носителей», которые… Ну в общем их и видеть не стоит :)
Ошибки и опечатки, скорее, не позволяют утверждать, что вам стоит работать учителем русского языка в РФ, ну а всё остальное — на уровне, который много выше некоторых реальных «носителей», которые из всех видов русского языка знают только матерный :)
И мне туда же.
Но джойны в РСУБД ликвидируются просто (если нужно), а вот реляционная модель со всеми удобствами в нереляционных базах нереализуема (ибо очень дорого). В сумме РСУБД может не хуже NoSQL, а NoSQL не может как РСУБД.
Есть отдельные узкие ниши, где отказ от РСУБД может ускорить некоторые виды обработки данных, но ускорение получается так себе (хотя может кому-то важно хотя бы 20-40% роста в обмен на отказ от всем привычного и гибкого). А в плане удобства работы с документами — просто используем приличный ORM и опять NoSQL становится ненужным.
Но да, я не спора ради, я пробую простую идею донести — в массовом применении РСУБД объективно лучше, а массовая популяризация NoSQL ради каких-то узких ниш — совершенно не оправдана.