unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images.
Ну вы рано или поздно просто огребете, что ваш абсолютно спозиционированный элемент начнет вычислять свои координаты относительно первого же предка. Это не так чтобы проблема (на первый взгляд), но неочевидно.
Еще понаогребаете с z-index'ами, их у вас будет чуть ли не на каждый элемент, который следует за родительским блоком абсолютно спозиционированной ноды.
Еще селекторы * — очень медленные и ускорить их вообще нечем.
Вдобавок ко всему это совсем неочевидно. Все равно как если бы в вашем проекте все классы реализовывали бы некий интерфейс IMyInteface, в котором есть какой-то метод, вообще мало что имеющий общего с большей частью реализаций.
И я с вами тоже соглашусь, поскольку так и есть. Но многие вышевысказавшиеся, и я в их числе, имели в виду, что важно не столько дать инструмент и научить с ним работать, сколько научить искать и создавать инструменты и самостоятельно учиться с ними работать.
Если речь идет об образовании в пять лет, нет такой специальности, которая потребовала бы пятилетнего обучения работе с набором инструментов. Это инструкция к баттлшип «Галактика» получится. А вот за пять лет научить гуглить, научить делать выводы, использовать отвертки для забивания гвоздей (когда нет молотка), но не использовать для этого микроскопы — это. в принципе, реально. И особенно это полезно для студентов, которые не вполне понимают, для чего им конкретно это образование (а вы, помнится, выше предположили, что таковых большинство).
Так не бывает. Возникнет третья задача, в которой надо сочетать ряды Фурье и еще какую-то тему G. А одновременно с конденсаторами ее дать нельзя. Вы предлагаете заточить человека не просто под конкретную специальность, а под достаточно ограниченный массив задач конкретной специальности. Как говорил Козьма Прутков «специалист подобен флюсу». А ваш сферический пример в вакууме подобен квантовому компьютеру (и речь не только об ограниченности круга применения, а еще и времени жизни — я бы такого убил, ведь он ряды Фурье может применить только к конденсаторам, а к быстрому сложению уже не может).
PS: Либо может, но тогда уже некорректна поставленная вами необходимость давать одновременно ряды Фурье и конденсаторы.
Видели, конечно. Но тут несколько вариантов. Среди них:
1. Вышеупомянутая личность занималась вышеупомянутой зубрежкой, помнит, что функция раскладывается в ряд Фурье и про гармоники помнит. То же самое и про конденсаторы. Когда речь заходит о конкретной задаче, память ему ничего не подсказывает, и он виснет. Ровно то, о чем я сказал: «зубрёжка — зло».
2. Вышеупомянутая личность прискорбно невежественна и не может вывести силлогизм, чуть более сложный чем modus ponens. Такие в качестве примера не подходят.
3. Вышеупомянутая личность училась прилежно и с интересом и понимает, что такое ряд Фурье не только на уровне определения, рассматривает конденсатор не только как две пластинки + диэлектрик. Но не знает, что такое RC фильтр. Дайте ей гугл (чтобы прочитать, что это такое), и она «развиснет» достаточно быстро. ИМХО. Возможно, я ошибаюсь.
Мне кажется, часто в совершенно левой задаче можно найти применение любимому инструменту. Конечно, слесарь вряд ли сможет закрутить саморез пассатижами, но вот математик, который использовал теорему Силова в оптимизации какого-нибудь алгоритма над ориентированным графом — это нередкое явление. Такие решения, внезапно, требуют широты теоретических знаний и понимания работы не только одной области математики, а целого спектра этих областей, их взаимодействий и пересечений. И именно такие решения потом остаются в памяти поколений.
Откуда товарищу Галуа было знать, что его изучения конечных полей в итоге очень помогут доказать ВТФ (под говорящей аббревиатурой подразумевалась великая теорема Ферма)?
Если чистая наука оказалась для вас ненужным балластом, это не хорошо и не плохо — просто задачи, с которыми сталкиваетесь вы, сугубо практические, сиюминутные (в сравнении с фундаментальными задачами). Но не надо экстраполировать. Чистая наука бесполезна для одного человека — и безмерно важна для человечества в целом.
Математика не поддается изучению путем зубрежки. Да, конечно, на определенном этапе (школьном), можно выезжать на том, что вы выучили наизусть. Но как только речь заходит о сколько-нибудь интересных (а потому сложных) областях математики, памяти категорически не хватает. Разве что особо памятливым.
Понимание не подразумевает запоминания. Я не помню доказательства ни одной теоремы из курса того же матана, но мне и не надо их помнить. Достаточно условия задачи и необходимых определений (увы, я тоже не все уже помню, но мы же не в «меморию» играем?), и человек с __адекватной__ математической подготовкой, который получал оценки не потому что выучил наизусть антидемидовича, а потому что сидел и вникал, все сам докажет.
В общем, вы выяснили, что первый программист пишет код, который в долгосрочной перспективе вообще не будет читаемым и поддерживаемым хоть в какой-то степени. Про скорость работы тоже сказать нечего, поскольку ветвления всякие бывают, и не всегда их на else-if'ах вывезти можно.
Вы бы дали им обоим прочитать про паттерны «Стратегия» или «Цепочка обязанностей», они бы умнее стали, код, глядишь, лучше выглядел бы. А вы его минифицируйте, если так за количество строк радеете.
Мне кажется, статьи, в которых рассказывается про прототипирование, контекст и замыкания в JS, появляются на хабре примерно раз в два месяца. И там обязательно одни и те же комментарии. Например, подобные моему. Сансара.
Вы абсолютно правы, собственно, именно это и имел в виду Макконнелл, говоря про комментирование намерений. Но в данном топике народ старательно путает намерения и реализацию.
Что касается сортировки… Мне лично кажется, что если в ситуации допустимо использование нескольких сортировок, лучше воспользоваться каким-то паттерном, наподобие композита. Читающему код будет понятно, что в каждом конкретном вызове композитного сортировщика выполняется какая-то сортировка, а какая именно — будет отлично видно в названии класса-сортировщика.
В случае если мы вдруг при живом квиксорте решили воспользоваться пузырьком, конечно, комментарий следует написать, но именно как описание некоего магического знания: «Здесь мы проседаем по памяти». Потому как в противном случае (вместо названия писать суть в комментарии) придется писать комментарий на каждый вызов этой сортировки.
Правильное решение — вынести проверку в отдельный метод: скажем,
CharIsHexSymbol(c) {
return c > '0' && c < 'F';
}
Код сам себя успешно комментирует, и это допустимо почти в любой ситуации. Ну все примеры, которые народ приводил, все поголовно используют комментарии там, где можно использовать инкапсуляцию.
Согласен, что иногда комментариев не избежать, но уж, имхо, точно не в случае с пустым ELSE. Тудухи — в тудухи, если вы на своих проектах забиваете на тудухи, то это проблема не тудух, а ваших проектов.
Еще интересный вариант задачи — приближенный к реальным условиям. В детстве частенько игра затягивалась на девять-десять ходов из-за того, что кто-то случайно «лгал» оппоненту, оценивая предложенный им вариант. Было бы круто написать программу, угадывающую число, получая данные с потерями =)
С точки зрения производительности это то же самое, что и "#upload, #fileformlabel". Descendant селекторы читаются справа налево, ЕМНИП, а #id-селекторы работают до первого совпадения.
Мне кажется, это зависит целиком от паттерна, который используется в конкретной задаче. Например в стандартную иерархическую модель вполне укладываются и события, и вызовы методов. Но там вполне себе дерево, нет никаких сложных связей, события выглядят семантично и даже в некотором роде удобно. Берем штуку со связами посложнее — и сеть событий сразу делает ее нерасширяемой, усиливая связанность.
Так что идея экстраполировать какой-то подход на весь ООП мне лично кажется несколько надуманной. К православному ООП ближе не события и не методы, если уж на то пошло, а структурность и модульность.
Круто, что именно этим я и промышляю.
Еще понаогребаете с z-index'ами, их у вас будет чуть ли не на каждый элемент, который следует за родительским блоком абсолютно спозиционированной ноды.
Еще селекторы * — очень медленные и ускорить их вообще нечем.
Вдобавок ко всему это совсем неочевидно. Все равно как если бы в вашем проекте все классы реализовывали бы некий интерфейс IMyInteface, в котором есть какой-то метод, вообще мало что имеющий общего с большей частью реализаций.
Пользуйте Mercurial!
Если речь идет об образовании в пять лет, нет такой специальности, которая потребовала бы пятилетнего обучения работе с набором инструментов. Это инструкция к баттлшип «Галактика» получится. А вот за пять лет научить гуглить, научить делать выводы, использовать отвертки для забивания гвоздей (когда нет молотка), но не использовать для этого микроскопы — это. в принципе, реально. И особенно это полезно для студентов, которые не вполне понимают, для чего им конкретно это образование (а вы, помнится, выше предположили, что таковых большинство).
PS: Либо может, но тогда уже некорректна поставленная вами необходимость давать одновременно ряды Фурье и конденсаторы.
1. Вышеупомянутая личность занималась вышеупомянутой зубрежкой, помнит, что функция раскладывается в ряд Фурье и про гармоники помнит. То же самое и про конденсаторы. Когда речь заходит о конкретной задаче, память ему ничего не подсказывает, и он виснет. Ровно то, о чем я сказал: «зубрёжка — зло».
2. Вышеупомянутая личность прискорбно невежественна и не может вывести силлогизм, чуть более сложный чем modus ponens. Такие в качестве примера не подходят.
3. Вышеупомянутая личность училась прилежно и с интересом и понимает, что такое ряд Фурье не только на уровне определения, рассматривает конденсатор не только как две пластинки + диэлектрик. Но не знает, что такое RC фильтр. Дайте ей гугл (чтобы прочитать, что это такое), и она «развиснет» достаточно быстро. ИМХО. Возможно, я ошибаюсь.
Откуда товарищу Галуа было знать, что его изучения конечных полей в итоге очень помогут доказать ВТФ (под говорящей аббревиатурой подразумевалась великая теорема Ферма)?
Если чистая наука оказалась для вас ненужным балластом, это не хорошо и не плохо — просто задачи, с которыми сталкиваетесь вы, сугубо практические, сиюминутные (в сравнении с фундаментальными задачами). Но не надо экстраполировать. Чистая наука бесполезна для одного человека — и безмерно важна для человечества в целом.
Понимание не подразумевает запоминания. Я не помню доказательства ни одной теоремы из курса того же матана, но мне и не надо их помнить. Достаточно условия задачи и необходимых определений (увы, я тоже не все уже помню, но мы же не в «меморию» играем?), и человек с __адекватной__ математической подготовкой, который получал оценки не потому что выучил наизусть антидемидовича, а потому что сидел и вникал, все сам докажет.
Вы бы дали им обоим прочитать про паттерны «Стратегия» или «Цепочка обязанностей», они бы умнее стали, код, глядишь, лучше выглядел бы. А вы его минифицируйте, если так за количество строк радеете.
Что касается сортировки… Мне лично кажется, что если в ситуации допустимо использование нескольких сортировок, лучше воспользоваться каким-то паттерном, наподобие композита. Читающему код будет понятно, что в каждом конкретном вызове композитного сортировщика выполняется какая-то сортировка, а какая именно — будет отлично видно в названии класса-сортировщика.
В случае если мы вдруг при живом квиксорте решили воспользоваться пузырьком, конечно, комментарий следует написать, но именно как описание некоего магического знания: «Здесь мы проседаем по памяти». Потому как в противном случае (вместо названия писать суть в комментарии) придется писать комментарий на каждый вызов этой сортировки.
Код сам себя успешно комментирует, и это допустимо почти в любой ситуации. Ну все примеры, которые народ приводил, все поголовно используют комментарии там, где можно использовать инкапсуляцию.
Согласен, что иногда комментариев не избежать, но уж, имхо, точно не в случае с пустым ELSE. Тудухи — в тудухи, если вы на своих проектах забиваете на тудухи, то это проблема не тудух, а ваших проектов.
Так что идея экстраполировать какой-то подход на весь ООП мне лично кажется несколько надуманной. К православному ООП ближе не события и не методы, если уж на то пошло, а структурность и модульность.