Вообще таки можно возвращать объект, если хочется что-то кастомное сконструировать.
this.greet = function () {
Возможно конечно JIT это заоптимизирует, а возможно и нет, либо не сразу, а после сотни вызовов. По факту вы советуете способ, замедляющий код, потому что каждый раз при создании объекта у нас будет создаваться новая функция. Очень плохой совет. Ну а если такое на собеседовании сделать и на той стороне не джун-собеседующий сидит - сразу отказ.
Итог
Ужасная статья, советующая плохие подходы. Автор заявляет что он преподаватель веб-разработки. Будет грустно за его студентов.
ООП грех, поэтому будем создавать всё через функцую, которая не конструктор, но конструирует компонент, но не конструктор, потому что слово конструктор - грех, а ООП зло. И переменные внутри это именно переменные, ничем не похожие на поля класса по своему принципу работы, потому что поля классов это грех, запретное слово, потому что ООП.
Автокомплит методов считается? В принципе до эры хайпа уже давно у JetBrains в IDE нейросеть пыталась понять что ты сейчас напишешь и когда ты ставил точку чтобы написать метод - подбирала максимально подходящий. Ну и прочие точечные подсказки-предсказания. Тогда это просто называлось умная IDE.
А вот полнострочный и, тем более, многострочный комплит у меня отключен. Как верно заметили выше - проще писать самому чем читать и справлять нагенеренное. Автокомплит хотя бы учитывает какие реально методы существуют, по типу возврата у функции что-то предложить, да даже имя переменной на основе шаблона других перед этим. А вот всё остальное что сейчас называется ИИ может придумать что угодно и нужно вчитываться, что сбивает контекст.
А это не оптимизм. Это просто есть как есть. Когда появился фотошоп рисовать всё руками в чем-то уровня Paint стало не рентабельно и те веб-дизайнеры, которые не освоили - остались без работы. Профессиональному математику сложновато с без калькулятора. Одежда ручной работы всё ещё производится, но почти все люди планеты носят фабричное. Ну и, в конце концов, засеивать поля руками при конкуренции с трактором тоже сомнительная бизнес-идея. Конечно на такое будет покупатель, но это единичный продукт.
Нейросети сломали старые бизнес процессы некоторых сфер, именно некоторых, но сломали. И ты либо живёшь в новом мире и адаптируешься, либо тебя съедят.
Джин уже выпущен, блокировка будет лишь борьбой с неизбежным и те кто будут блокировать - проиграют остальным. Нужно адаптироваться под новую реальность. Одни бизнес-процессы умерли, но другие только что родились.
Я вот много людей встречал, но ни один не смог заработать на технических индикаторах. Именно тех, которые встроены везде и всюду. Во всех ста процентах случаев это была временная корреляция. Была безумная история с человеком, который с 20к баксов сделал 400к, и потом три года на это жил. Потому что через полгода стратегия перестала работать, а новую стабильную корреляцию найти он не смог. Но у большинства корреляция разваливается быстрее, либо человек верит в неё до конца и назад деньги в биржу отдаёт.
Подсознание нас обманывает. Видя повторяющиеся одинаковые события человек видит в них закономерность и возможность использовать. Но человек ли только? Был эксперимент на голубях, когда их сажали в клетки с нажимной кнопкой. И иногда сыпался корм. Через некоторое время у голубей появлялись ритуальные танцы. Потому что они запоминали что именно происходило перед падением корма и повторяли. Только вот корм сыпался случайным образом.
В реальной жизни появление закономерности часто не случайно и реально можно что-то из этого получить, как минимум какое-то время. Отточенное миллионами лет умение. Но есть вещи, которые просто случайные совпадения. Но случайность и неизвестность может таить опасность и мозг не может успокоиться, пока не найдёт хоть какое-то логическое объяснение. Оттуда вера в древних богов, астрология и технические индикаторы на бирже.
Там главное чтобы оба ордера исполнились, потому что цена может безоткатно полететь в сторону и всё, зависший ордер, который могут протащить на пару процентов. В итоге один такой может съесть штук 60 успешных, а то и 160.
Низкоуровневый, но и не избыточно детальный. Не так и сильно отличается по количеству необходимого кода в процессе написания, нет низкоуровневого бойлерплейта. Разве чуть подбешивает писать везде &self, ну и там любителям ссылок на два элемента массива привет. Высокоуровневую логику писать примерно столько же как в TypeScript.
Кстати, раньше для этого был флеш и джава аплеты. Ну и во времена совсем доминации майкрософта - актив икс. Не могу сказать что так лучше, а умерло по сути потому что не шло из коробки с браузером. Можно сказать про тормоза и дыры, но можно и на современные сайты-приложения посмотреть и сравнить потребление памяти - флеш не такой и суровый был. Впрочем, решение через JS мне нравится больше.
Ну вообще плеер вполне может быть Html в чистом виде. Уверен что если чуть-чуть допилить с буферизацией и прочим - можно было бы получить ютуб. Вот с загрузкой без перезагрузки всей страницы - вопросик. Но в теории можно было бы допилить стандарт до поллинг-тегов или даже реалтайм, на том же xml который представляет html. Гугл карты из чанков картинок состоят и поллинг-тегами решаемо. Поллинг может быть и поточный с тем же вебсокетом.
Ну в общем в принципе с минимальными доработками можно было бы получить большинство типа контента, включая динамический. Разве что вот игры и всякое совсем лютое с канвасами уже не получилось бы.
Так то и представленный тег детейлс можно div и скриптом. И половину анимаций. И даже flex-box был на IE6 и я лично делал, вот прям с той же функциональностью, но через JS используя либу ExtJS.
Просто стандарты не успевали за потребностями, потому появился Тьюринг-полный язык и делайте что хотите, а стандарты потом докрутим. И докручивают, вынося самое популярное в новые теги и css-стили. Просто с отрывом в пяток лет.
Далеко ходить не надо - у меня тут проект, часть платежной системы, которую планируют заморозить потому что добавление новых фич стало занимать столько времени что на зарплаты уходит больше чем доходы с комиссий от клиентов. При этом количество клиентов не поменялось. То есть это на столько рядом что деньгами касается меня лично. А потому что сначала несколько лет писали как придётся потому что бизнес ждет уже вчера, а не было того кто сказал бы нет. Или того кто проактивно ввёл бы культуру разработки. Результат - прошли годы, добавление фичи выглядящей на три дня работы занимает два месяца, буквально.
В этом и проблема - забывают проверить, либо делают как в меме про и так сойдёт. А тут тебе компилятор скажет что есть шанс отстрелить пол-ноги, давай-ка решим этот вопросик.
Наоборот получалось обычно - была проблема с производительностью, я заходил, а там помимо всего прочего не редко массивы с пачкой данных копировались вместо модификаций, цепочки вызовов над массивами с преобразованиями, порождающими новые массивы и прочее такое. И вот когда в один проход переписывалось или с мутабельностью - скорость росла вот прямо по метрикам было видно. А кое-какой код вообще не работал в моменте, потому что бывает что полтора гигабайта json в приложение на nodejs заходит за раз без потока и там все способы работы привычные уже не способны существовать в принципе. Ну и конечно порождение квадратичных алгоритмов. В общем я видел некоторое волшебство и, конечно же, концепт иммутабельности решает множество проблем, меньше багов, но вот когда возводится идея в абсолют - потом приходится ходить и переписывать код.
Хаскелл в продакшене встречается на столько редко что пример не подходящий. И база данных не для всего решение. Потому что результат из базы тоже можно начать весело обрабатывать, вот половина проблем из моего опыта оптимизации тормозов - именно на этом этапе.
Второй — это иммутабельность, то есть отсутствие повторных присваиваний переменных и изменений существующих значений.
А потом чего это у нас код тормозит, надо серверов то добавить, да и базу подтюнить. И клиент как-то много памяти ест, но ничего, пользователь планочку памяти всегда может докупить.
Ох, как часто я встречал тормоза и неадекватное потребление памяти из-за того что выбрали иммутабельность как правило. И нет, не только потому что его готовить не умеют. Компьютер он абстрактно работать не умеет, там на дне нули и единицы и если ты их оставляешь лежать потому что иммутабельность - они так и лежат. Сборщик мусора, возможно их очистит. Возможно. Съев пачку тактов процессора на анализ. Впрочем, засорить можно и на том же Расте.
Если вы можете - никогда не используете иммутабельность, пожалейте других людей.
Он коверкает определение чистой функции, по сути, применяя её только с позиции публичных методов.
Ну вообще по ООП в идеале у тебя во вне смотрят публичные методы и свойства, а то что происходит внутри - оно на то и внутри. Просто не надо считать метод функцией, даже если в вашем языке программирования префикс fn, func или что-то подобное. Функция в объекте привязана к данным в объекте. А вот если она ходит куда-то во вне - вот это уже проблема и грязь, в контексте чистоты функций. Функциональное программирование и объекто-ориентированное это разные вещи. Конечно никто не мешает делать все методы у класса чистыми функциями, но тогда это модуль или неймспейс, а не класс в его основном понимании.
А чего бы нет? Сложнее понять - сложнее внедрять фичи - больше времени на разработку - больше расходы - расходы стали больше доходов. Не такая и редкость.
Вообще таки можно возвращать объект, если хочется что-то кастомное сконструировать.
Возможно конечно JIT это заоптимизирует, а возможно и нет, либо не сразу, а после сотни вызовов. По факту вы советуете способ, замедляющий код, потому что каждый раз при создании объекта у нас будет создаваться новая функция. Очень плохой совет. Ну а если такое на собеседовании сделать и на той стороне не джун-собеседующий сидит - сразу отказ.
Ужасная статья, советующая плохие подходы. Автор заявляет что он преподаватель веб-разработки. Будет грустно за его студентов.
ООП грех, поэтому будем создавать всё через функцую, которая не конструктор, но конструирует компонент, но не конструктор, потому что слово конструктор - грех, а ООП зло. И переменные внутри это именно переменные, ничем не похожие на поля класса по своему принципу работы, потому что поля классов это грех, запретное слово, потому что ООП.
У меня когда-то авто-фильтр матов для чата на сайте на Ucoz в 2009 заменял звездочками часть слова «чебурашка». Угадайте какие из трёх букв в слове.
Контекст важен 🙂
Автокомплит методов считается? В принципе до эры хайпа уже давно у JetBrains в IDE нейросеть пыталась понять что ты сейчас напишешь и когда ты ставил точку чтобы написать метод - подбирала максимально подходящий. Ну и прочие точечные подсказки-предсказания. Тогда это просто называлось умная IDE.
А вот полнострочный и, тем более, многострочный комплит у меня отключен. Как верно заметили выше - проще писать самому чем читать и справлять нагенеренное. Автокомплит хотя бы учитывает какие реально методы существуют, по типу возврата у функции что-то предложить, да даже имя переменной на основе шаблона других перед этим. А вот всё остальное что сейчас называется ИИ может придумать что угодно и нужно вчитываться, что сбивает контекст.
А это не оптимизм. Это просто есть как есть. Когда появился фотошоп рисовать всё руками в чем-то уровня Paint стало не рентабельно и те веб-дизайнеры, которые не освоили - остались без работы. Профессиональному математику сложновато с без калькулятора. Одежда ручной работы всё ещё производится, но почти все люди планеты носят фабричное. Ну и, в конце концов, засеивать поля руками при конкуренции с трактором тоже сомнительная бизнес-идея. Конечно на такое будет покупатель, но это единичный продукт.
Нейросети сломали старые бизнес процессы некоторых сфер, именно некоторых, но сломали. И ты либо живёшь в новом мире и адаптируешься, либо тебя съедят.
Джин уже выпущен, блокировка будет лишь борьбой с неизбежным и те кто будут блокировать - проиграют остальным. Нужно адаптироваться под новую реальность. Одни бизнес-процессы умерли, но другие только что родились.
Я вот много людей встречал, но ни один не смог заработать на технических индикаторах. Именно тех, которые встроены везде и всюду. Во всех ста процентах случаев это была временная корреляция. Была безумная история с человеком, который с 20к баксов сделал 400к, и потом три года на это жил. Потому что через полгода стратегия перестала работать, а новую стабильную корреляцию найти он не смог. Но у большинства корреляция разваливается быстрее, либо человек верит в неё до конца и назад деньги в биржу отдаёт.
Подсознание нас обманывает. Видя повторяющиеся одинаковые события человек видит в них закономерность и возможность использовать. Но человек ли только? Был эксперимент на голубях, когда их сажали в клетки с нажимной кнопкой. И иногда сыпался корм. Через некоторое время у голубей появлялись ритуальные танцы. Потому что они запоминали что именно происходило перед падением корма и повторяли. Только вот корм сыпался случайным образом.
В реальной жизни появление закономерности часто не случайно и реально можно что-то из этого получить, как минимум какое-то время. Отточенное миллионами лет умение. Но есть вещи, которые просто случайные совпадения. Но случайность и неизвестность может таить опасность и мозг не может успокоиться, пока не найдёт хоть какое-то логическое объяснение. Оттуда вера в древних богов, астрология и технические индикаторы на бирже.
Там главное чтобы оба ордера исполнились, потому что цена может безоткатно полететь в сторону и всё, зависший ордер, который могут протащить на пару процентов. В итоге один такой может съесть штук 60 успешных, а то и 160.
Низкоуровневый, но и не избыточно детальный. Не так и сильно отличается по количеству необходимого кода в процессе написания, нет низкоуровневого бойлерплейта. Разве чуть подбешивает писать везде &self, ну и там любителям ссылок на два элемента массива привет. Высокоуровневую логику писать примерно столько же как в TypeScript.
Кстати, раньше для этого был флеш и джава аплеты. Ну и во времена совсем доминации майкрософта - актив икс. Не могу сказать что так лучше, а умерло по сути потому что не шло из коробки с браузером. Можно сказать про тормоза и дыры, но можно и на современные сайты-приложения посмотреть и сравнить потребление памяти - флеш не такой и суровый был. Впрочем, решение через JS мне нравится больше.
Ну вообще плеер вполне может быть Html в чистом виде. Уверен что если чуть-чуть допилить с буферизацией и прочим - можно было бы получить ютуб. Вот с загрузкой без перезагрузки всей страницы - вопросик. Но в теории можно было бы допилить стандарт до поллинг-тегов или даже реалтайм, на том же xml который представляет html. Гугл карты из чанков картинок состоят и поллинг-тегами решаемо. Поллинг может быть и поточный с тем же вебсокетом.
Ну в общем в принципе с минимальными доработками можно было бы получить большинство типа контента, включая динамический. Разве что вот игры и всякое совсем лютое с канвасами уже не получилось бы.
Так то и представленный тег детейлс можно div и скриптом. И половину анимаций. И даже flex-box был на IE6 и я лично делал, вот прям с той же функциональностью, но через JS используя либу ExtJS.
Просто стандарты не успевали за потребностями, потому появился Тьюринг-полный язык и делайте что хотите, а стандарты потом докрутим. И докручивают, вынося самое популярное в новые теги и css-стили. Просто с отрывом в пяток лет.
Далеко ходить не надо - у меня тут проект, часть платежной системы, которую планируют заморозить потому что добавление новых фич стало занимать столько времени что на зарплаты уходит больше чем доходы с комиссий от клиентов. При этом количество клиентов не поменялось. То есть это на столько рядом что деньгами касается меня лично. А потому что сначала несколько лет писали как придётся потому что бизнес ждет уже вчера, а не было того кто сказал бы нет. Или того кто проактивно ввёл бы культуру разработки. Результат - прошли годы, добавление фичи выглядящей на три дня работы занимает два месяца, буквально.
К сожалению, это не единственный случай.
Согласен, можно сразу писать без багов. Непонятно, почему люди так не делают…
В этом и проблема - забывают проверить, либо делают как в меме про и так сойдёт. А тут тебе компилятор скажет что есть шанс отстрелить пол-ноги, давай-ка решим этот вопросик.
Наоборот получалось обычно - была проблема с производительностью, я заходил, а там помимо всего прочего не редко массивы с пачкой данных копировались вместо модификаций, цепочки вызовов над массивами с преобразованиями, порождающими новые массивы и прочее такое. И вот когда в один проход переписывалось или с мутабельностью - скорость росла вот прямо по метрикам было видно. А кое-какой код вообще не работал в моменте, потому что бывает что полтора гигабайта json в приложение на nodejs заходит за раз без потока и там все способы работы привычные уже не способны существовать в принципе. Ну и конечно порождение квадратичных алгоритмов. В общем я видел некоторое волшебство и, конечно же, концепт иммутабельности решает множество проблем, меньше багов, но вот когда возводится идея в абсолют - потом приходится ходить и переписывать код.
Хаскелл в продакшене встречается на столько редко что пример не подходящий. И база данных не для всего решение. Потому что результат из базы тоже можно начать весело обрабатывать, вот половина проблем из моего опыта оптимизации тормозов - именно на этом этапе.
А потом чего это у нас код тормозит, надо серверов то добавить, да и базу подтюнить. И клиент как-то много памяти ест, но ничего, пользователь планочку памяти всегда может докупить.
Ох, как часто я встречал тормоза и неадекватное потребление памяти из-за того что выбрали иммутабельность как правило. И нет, не только потому что его готовить не умеют. Компьютер он абстрактно работать не умеет, там на дне нули и единицы и если ты их оставляешь лежать потому что иммутабельность - они так и лежат. Сборщик мусора, возможно их очистит. Возможно. Съев пачку тактов процессора на анализ. Впрочем, засорить можно и на том же Расте.
Если вы можете - никогда не используете иммутабельность, пожалейте других людей.
Ну вообще по ООП в идеале у тебя во вне смотрят публичные методы и свойства, а то что происходит внутри - оно на то и внутри. Просто не надо считать метод функцией, даже если в вашем языке программирования префикс fn, func или что-то подобное. Функция в объекте привязана к данным в объекте. А вот если она ходит куда-то во вне - вот это уже проблема и грязь, в контексте чистоты функций. Функциональное программирование и объекто-ориентированное это разные вещи. Конечно никто не мешает делать все методы у класса чистыми функциями, но тогда это модуль или неймспейс, а не класс в его основном понимании.
А чего бы нет? Сложнее понять - сложнее внедрять фичи - больше времени на разработку - больше расходы - расходы стали больше доходов. Не такая и редкость.
Если ты не платишь - то товар это ты. Каждый выбирает своё.