О, вот и мне только что подумалось... А не написать ли мне и свое. А то пока написал UI тулзы для составления базы карточек (я веду список новых незнакомых слов) с помощью локальной LLM-ки (под ollama), из которой дергается word definition и примеры простых предложений, плюс транскрипция (хотя ее надежней брать онлайн, эта LLM-ка их не идеально "вытаскивает" из себя. А ведь можно ж сразу все-в-одном тогда написать.
Даже удобней так будет, если, вдруг, какой-то пример предложения мне потом не понравится. Нажму кнопку "перегенерировать" и выберу из списка предложенных. Надо подумать... И TTS-ку локальную тоже можно подключить. И StableDiffusion для генерации визуального образа. Заранее очень лень такое готовить (не все можно адекватно визуализировать, не так просто LLM-ку заставить тексом описать образ/сцену и т.д.) , а во время изучения конкретного слова, возможно, будет не лень.
P.S. СКРУПулезно (я когда-то тоже удивился)
P.P.S
никто не рассказал про интервальное запоминание, пока я ещё был школьником или студентом
А я школьником на ZX Spectrum написал запоминалку-тренажер английских слов, где экран был разбит на 2 половины. И нужно было правильно сопоставлять русские и английские слова. По завершению каждого уровня даже какая-то анимация у меня была. :) Еще не интервальное запоминание, но уже computer-driven подход.
Я перед написанием того своего комментария зашел на его блог, сразу нашел там ссылку на его выступление в каком-то рос. городе на чистом русском языке. Заняло секунды.
С учётом того, что это перевод, дядя абсолютно точно не инженер.
Русская фамилия не означает русскоязычность.
Ну так и "непереводность" не означает "неинженерность". :)
Странное это вот "абсолютно точно", если "перевод". Тут же легко увидеть имя автора прям в статье - Nikita Lapkov. И легко кликнуть по ссылке и увидеть, что это просто англоязычный блог русскоязычного автора (см. About).
Вот это как раз полностью совпадает с моими выводами. Я бы еще его назвал "паттерно-ориентированное" мышление (вместо аналитического). Плюс еще отдельный сложный для многих навык -- прогонять алгоритмы у себя в голове.
Вот я как раз про это. Навыка нет. Они просто всегда оперировали лишь паттернами. Повторение того, что в них влили. Я их называю "люди-флешки". :) Но я не верю, что там какие-то "перманентные блоки" у них в устройстве мозгов. Думаю, все поправимо, хоть и более мелкими шажками.
с логической точки зрения
О, кстати. Когда-то узнал, что есть в интернете тесты на логику. Вроде таких:
"Все крокодилы умеют летать. Все великаны являются крокодилами. Значит, все великаны могут летать. "
Сначала я сильно удивился, когда увидел, что куча людей реально испытывает сложности с такими тестами. :) Нет, ну я понимаю, если тут разброс по кол-ву секунд, необходимых на обдумывание и осмысление. Но как тут можно в целом можно ошибиться (без учета ошибок от невнимательности). А вот люди берут да и ошибаются! :) И еще даже спорят между собой на тему каких-то задачек.
Потом понял, что вот так вот и живут люди, не включая ту зону мозга вообще, которая задействована при решении таких "задачек". Ну не привыкли они. Сложно им удержать всю цельную конструкцию в голове.
Невосприимчивость абстракций и проблемы с логикой.
Вот, кстати, да. Тоже такое встречал, но так и не решил, перманентная там проблема, либо нет. Так как человек не хотел ничего воспринимать, а я просто попытался достучаться. :)
Вне всяких сомнений, размеры различных зон мозга у людей варьируют. Это как раз тот самый "талант", легкость в некоторых навыках. Но я не думаю, что существует именно жесткий барьер, блокирующий осознание сложных для них вещей. Мне кажется, у некоторых это просто полностью непрокачанный навык, которым люди не занимались никогда в жизни. Вот как-то так получилось. И если их пытаться заставить включать эту часть мозга, то им становится ну оооочень некомфортно. И нужно много времени, чтобы эту зону "прогреть", нарастить новые связи нейронные и т.д.
Эх... А у меня вот как раз есть стойкая уверенность в том, что я могу обучить любого, с гарантией. :) Мне 43, я все еще непрерывно всему новому самообучаюсь. Постоянно. А самообучаться я начал еще в школе. Что химию я знал на год вперед, так как "взял" книжку со школы и изучил ее летом (я тогда увлекался химией, опытами, пиротехникой), что информатика (я писал решения задачек на двух языках и еще и блок-схемах, а еще рассказывал молодой информатичке про "архитектуру" программ, которые я писал на ZX Spectrum, а она с удивлением и интересом меня слушала. :)
Просто изложить какой-то материал -- вообще бессмысленная трата времени. Суть очного обучения как раз в том, чтобы "с толкача" включать осмысление информации у ученика. Контролировать это можно только вопросами. Если где-то произошел "затык", и человек не понимает какой-то момент, то нужно зайти с другой стороны, постараться придумать какую-то аналогию.
И нельзя наслаивать знания на неукрепленный фундамент. А, тем более, когда его вообще еще и нет. И задача учителя как раз контролировать каждый новый слой. Иначе ученик не здание построит из этих кирпичиков, а отложит их кучу. :)
А высший пилотаж -- не "вбивать" сложные для понимания концепции, а (через примеры) дать возможность ученику из "изобрести", логически вывести. Чтобы у ученика ВКЛЮЧИЛСЯ МОЗГ, нужно обозначить проблему, которую нужно решить. И в диалоге подводить его к решению, задавать наводящие вопросы, слушать весь поток мыслей, определяя по ходу слабые места, которые нужно укрепить. И, хотя такое обучение и будет очень-очень дорогим, оно будет бесконечно далеким по качеству конечного результата.
О чем речь? Не понял. Оно компилируется в чистый виндовый exe-шник ~ 400 килобайт (за счет довеска NIMа).
Нет, ну можно, конечно, написать чуть больше строк уже на Си, слинковать без рантайма... может 10-15 будет, не знаю, очень давно уже не проверял. Да оно и не интересно как-то даже. :)
Более того: чем уже тема, тем сложнее найти переводчика, который сможет во всем разобраться. :) А вот большим языковым моделям это как два токена принять. :)
Один раз у меня эта боль была многократно усилена. :) Помню, часа 2 программировал игру, так увлекся, а на кассету забыл сохранить состояние. А потом холодильник такой... "Добрый вечер!"... Ж8-[ ]
Это я привел пример САМОЙ ПРИЕМЛЕМОЙ модели. По факту вообще не надо делать никакой гавкающей собаки, так как ее невозможно смоделировать сколько-нибудь приближенно к реальному миру. А раз уж очень хочется, то пусть это будет что-то, что создают ее голосовые связки контактируя с воздухом среды и больше ни с чем. :) Условная вибрация воздуха, спектрограмма. Такая себе jailed-dog. Но если нам ничего не нужно будет кроме самого звука от этой собаки, то не фантазировать лишних абстракций, а реализовать именно генерацию аудио и на этом остановиться.
Я бы для более ясного примера предложил вариант, что "сферическая собака в вакууме" должна вернуть WAV файл. Но по неймингу я согласен с комментом выше. :) Например (не идеально), audio = dog.createBarkingWAV() А дальше это audio уже используй, накладывай куда угодно, проигрывай...
Почему не просто глагол bark()? Просто глагол подразумевает выполнение действия, команда. Но мы ж не делегируем собаке таких полномочий (хоть многие этим и излишне увлекаются, запутывая всю логику).
Правильным применением ООП печатание на консоль из собаки все равно не становится. Как и rectangle.draw(), когда фигура сама себя рисует на экране.
Отож. А потом сидят и думают ... "кто нам ком стоял" (с). :) И не могут эту связанность потом распутать.
Я так понимаю, главная причина появления этой каши в том, что многие пытаются моделировать объекты реального мира. Хотя им чаще всего нужно всего лишь разделить зоны ответственности кода (функционал) и продумать интерфейс взаимодействия этих функциональных модулей.
Та это все понятно. Мы ж про другое беседуем. Я про то, что не нужно именованные классы вводить там, где их не существует по смыслу. Но, конечно, это не касается языков, где по-другому ты просто не можешь сделать (Java/C#). :) Если язык позволяет создавать модуль -- его логичней всего и создавать в такой ситуации.
Нет, я про юнит-тесты своего кода. Интеграционные это если бы я на реальный диск писал.
Ну тут вопрос в терминологии. :) Для меня юнит-тест (тест модуля) -- это чистый тест функции обработчик_сценария_когда_диск_заполнен() без "дергания" другого юнита (модуля file_worker). Если его "дергаем", то это уже интеграция двух наших модулей (главный и "файловый").
Ну да не важно.
Ну и зачем нужны эти сложности, если можно просто использовать объекты? Судя по этой записи, file_worker это самый настоящий объект. Ну так о том и речь, что их удобно использовать.
Конечно можно назвать его объектом. Только классов тут никаких нет. :) Никакого мусорного лишнего кода и ненужных абстракций. Ни в главном коде, ни в модуле file_worker.
Или вообще реализация отладочного функционала в модуле file_worker. Мало ли, вдруг хочется имитировать различные сценарии дисковых ошибок. Тогда вот так одной строчкой "включаем" необходимый сценарий для тестирования, не засоряя наш основной код "чужим функционалом", не смешивая логику.
передаю отдельный "привет" питонщикам с ихним бл$дь self через слово)
:) Так и питонщики сами тихо офигевают, когда видят чей-то код, загаженный классами там, где реально нет никаких классов. Прочитай тут статью "Перестаньте писать классы", например.
Все так. Классы нужно/можно использовать только там, где есть реально динамическое число объектов одного рода, имеющих свои данные. Если это разделение функционала, то это банальный отдельный модуль (без всяких классов).
О, вот и мне только что подумалось... А не написать ли мне и свое. А то пока написал UI тулзы для составления базы карточек (я веду список новых незнакомых слов) с помощью локальной LLM-ки (под ollama), из которой дергается word definition и примеры простых предложений, плюс транскрипция (хотя ее надежней брать онлайн, эта LLM-ка их не идеально "вытаскивает" из себя. А ведь можно ж сразу все-в-одном тогда написать.
Даже удобней так будет, если, вдруг, какой-то пример предложения мне потом не понравится. Нажму кнопку "перегенерировать" и выберу из списка предложенных. Надо подумать... И TTS-ку локальную тоже можно подключить. И StableDiffusion для генерации визуального образа. Заранее очень лень такое готовить (не все можно адекватно визуализировать, не так просто LLM-ку заставить тексом описать образ/сцену и т.д.) , а во время изучения конкретного слова, возможно, будет не лень.
P.S. СКРУПулезно (я когда-то тоже удивился)
P.P.S
А я школьником на ZX Spectrum написал запоминалку-тренажер английских слов, где экран был разбит на 2 половины. И нужно было правильно сопоставлять русские и английские слова. По завершению каждого уровня даже какая-то анимация у меня была. :) Еще не интервальное запоминание, но уже computer-driven подход.
Я перед написанием того своего комментария зашел на его блог, сразу нашел там ссылку на его выступление в каком-то рос. городе на чистом русском языке. Заняло секунды.
Ну так и "непереводность" не означает "неинженерность". :)
Странное это вот "абсолютно точно", если "перевод". Тут же легко увидеть имя автора прям в статье - Nikita Lapkov. И легко кликнуть по ссылке и увидеть, что это просто англоязычный блог русскоязычного автора (см. About).
Вот это как раз полностью совпадает с моими выводами. Я бы еще его назвал "паттерно-ориентированное" мышление (вместо аналитического). Плюс еще отдельный сложный для многих навык -- прогонять алгоритмы у себя в голове.
Вот я как раз про это. Навыка нет. Они просто всегда оперировали лишь паттернами. Повторение того, что в них влили. Я их называю "люди-флешки". :) Но я не верю, что там какие-то "перманентные блоки" у них в устройстве мозгов. Думаю, все поправимо, хоть и более мелкими шажками.
О, кстати. Когда-то узнал, что есть в интернете тесты на логику. Вроде таких:
"Все крокодилы умеют летать. Все великаны являются крокодилами. Значит, все великаны могут летать. "
Сначала я сильно удивился, когда увидел, что куча людей реально испытывает сложности с такими тестами. :) Нет, ну я понимаю, если тут разброс по кол-ву секунд, необходимых на обдумывание и осмысление. Но как тут можно в целом можно ошибиться (без учета ошибок от невнимательности). А вот люди берут да и ошибаются! :) И еще даже спорят между собой на тему каких-то задачек.
Потом понял, что вот так вот и живут люди, не включая ту зону мозга вообще, которая задействована при решении таких "задачек". Ну не привыкли они. Сложно им удержать всю цельную конструкцию в голове.
Вот, кстати, да. Тоже такое встречал, но так и не решил, перманентная там проблема, либо нет. Так как человек не хотел ничего воспринимать, а я просто попытался достучаться. :)
Вне всяких сомнений, размеры различных зон мозга у людей варьируют. Это как раз тот самый "талант", легкость в некоторых навыках. Но я не думаю, что существует именно жесткий барьер, блокирующий осознание сложных для них вещей. Мне кажется, у некоторых это просто полностью непрокачанный навык, которым люди не занимались никогда в жизни. Вот как-то так получилось. И если их пытаться заставить включать эту часть мозга, то им становится ну оооочень некомфортно. И нужно много времени, чтобы эту зону "прогреть", нарастить новые связи нейронные и т.д.
Эх... А у меня вот как раз есть стойкая уверенность в том, что я могу обучить любого, с гарантией. :) Мне 43, я все еще непрерывно всему новому самообучаюсь. Постоянно. А самообучаться я начал еще в школе. Что химию я знал на год вперед, так как "взял" книжку со школы и изучил ее летом (я тогда увлекался химией, опытами, пиротехникой), что информатика (я писал решения задачек на двух языках и еще и блок-схемах, а еще рассказывал молодой информатичке про "архитектуру" программ, которые я писал на ZX Spectrum, а она с удивлением и интересом меня слушала. :)
Просто изложить какой-то материал -- вообще бессмысленная трата времени. Суть очного обучения как раз в том, чтобы "с толкача" включать осмысление информации у ученика. Контролировать это можно только вопросами. Если где-то произошел "затык", и человек не понимает какой-то момент, то нужно зайти с другой стороны, постараться придумать какую-то аналогию.
И нельзя наслаивать знания на неукрепленный фундамент. А, тем более, когда его вообще еще и нет. И задача учителя как раз контролировать каждый новый слой. Иначе ученик не здание построит из этих кирпичиков, а отложит их кучу. :)
А высший пилотаж -- не "вбивать" сложные для понимания концепции, а (через примеры) дать возможность ученику из "изобрести", логически вывести. Чтобы у ученика ВКЛЮЧИЛСЯ МОЗГ, нужно обозначить проблему, которую нужно решить. И в диалоге подводить его к решению, задавать наводящие вопросы, слушать весь поток мыслей, определяя по ходу слабые места, которые нужно укрепить. И, хотя такое обучение и будет очень-очень дорогим, оно будет бесконечно далеким по качеству конечного результата.
О чем речь? Не понял. Оно компилируется в чистый виндовый exe-шник ~ 400 килобайт (за счет довеска NIMа).
Нет, ну можно, конечно, написать чуть больше строк уже на Си, слинковать без рантайма... может 10-15 будет, не знаю, очень давно уже не проверял. Да оно и не интересно как-то даже. :)
Переключатель в 13 строк: minimal-caps-lock-lang-switcher
Более того: чем уже тема, тем сложнее найти переводчика, который сможет во всем разобраться. :) А вот большим языковым моделям это как два токена принять. :)
Это только если у тебя телевизор цветной был. :) А если выделили тебе ч/б с полусевшим кинескопом, то остается только лампы шатать иногда. :)
Один раз у меня эта боль была многократно усилена. :) Помню, часа 2 программировал игру, так увлекся, а на кассету забыл сохранить состояние. А потом холодильник такой... "Добрый вечер!"... Ж8-[ ]
И Спектрум "БЛЫЫЫММ!"... И сбросился.
Ха! У меня тоже такие рекламки есть. Я в те времена из газеты вырезал и в блокнотик себе клеил. :)
Это я привел пример САМОЙ ПРИЕМЛЕМОЙ модели. По факту вообще не надо делать никакой гавкающей собаки, так как ее невозможно смоделировать сколько-нибудь приближенно к реальному миру. А раз уж очень хочется, то пусть это будет что-то, что создают ее голосовые связки контактируя с воздухом среды и больше ни с чем. :) Условная вибрация воздуха, спектрограмма. Такая себе jailed-dog. Но если нам ничего не нужно будет кроме самого звука от этой собаки, то не фантазировать лишних абстракций, а реализовать именно генерацию аудио и на этом остановиться.
Я бы для более ясного примера предложил вариант, что "сферическая собака в вакууме" должна вернуть WAV файл. Но по неймингу я согласен с комментом выше. :) Например (не идеально), audio = dog.createBarkingWAV() А дальше это audio уже используй, накладывай куда угодно, проигрывай...
Почему не просто глагол bark()? Просто глагол подразумевает выполнение действия, команда. Но мы ж не делегируем собаке таких полномочий (хоть многие этим и излишне увлекаются, запутывая всю логику).
Отож. А потом сидят и думают ... "кто нам ком стоял" (с). :) И не могут эту связанность потом распутать.
Я так понимаю, главная причина появления этой каши в том, что многие пытаются моделировать объекты реального мира. Хотя им чаще всего нужно всего лишь разделить зоны ответственности кода (функционал) и продумать интерфейс взаимодействия этих функциональных модулей.
Та это все понятно. Мы ж про другое беседуем. Я про то, что не нужно именованные классы вводить там, где их не существует по смыслу. Но, конечно, это не касается языков, где по-другому ты просто не можешь сделать (Java/C#). :) Если язык позволяет создавать модуль -- его логичней всего и создавать в такой ситуации.
Ну тут вопрос в терминологии. :) Для меня юнит-тест (тест модуля) -- это чистый тест функции обработчик_сценария_когда_диск_заполнен() без "дергания" другого юнита (модуля file_worker). Если его "дергаем", то это уже интеграция двух наших модулей (главный и "файловый").
Ну да не важно.
Конечно можно назвать его объектом. Только классов тут никаких нет. :) Никакого мусорного лишнего кода и ненужных абстракций. Ни в главном коде, ни в модуле file_worker.
Аааа, вот ты про что. Ты про интеграционные тесты. Допустим, твой основной код выглядит как-то так:
И, как я понял, тебе мало модульных тестов (тестирования конкретного вызова "обработчик_этого_сценария() ").
Тогда тут уже зависит от желаемой глубины этой интеграции. Или простая строчка для подмены функции:
Или вообще реализация отладочного функционала в модуле file_worker. Мало ли, вдруг хочется имитировать различные сценарии дисковых ошибок. Тогда вот так одной строчкой "включаем" необходимый сценарий для тестирования, не засоряя наш основной код "чужим функционалом", не смешивая логику.
:) Так и питонщики сами тихо офигевают, когда видят чей-то код, загаженный классами там, где реально нет никаких классов. Прочитай тут статью "Перестаньте писать классы", например.
Все так. Классы нужно/можно использовать только там, где есть реально динамическое число объектов одного рода, имеющих свои данные. Если это разделение функционала, то это банальный отдельный модуль (без всяких классов).