Надеюсь не надо объяснять, почему те люди, которые ввели эту синтаксическую опцию в С++, должны сдохнуть и сгореть в аду (могу пояснить на пальцах почему).
CodeStyle & Design guide определите для проекта и будет вам счастье.
эксепшены, особенно когда они часть АПИ каких нибудь внешних зависимостей. Некоторым знаете ли такое по душе, а мне этих людей хочется начать бить уже сейчас.
А тут что не так или библиотеки не должны «материться» если вы в них пихаете всякую дрянь? :) Как еще библиотека скажет, что «у вас золотые руки, но от бедер растут потому что....»?
Точно в такой же мере, как и любой другой сервисный инструмент. Есть — хорошо, нету — ну и фиг с ним, сам сделаю.
2) не важно как он работает.
Не очень понято, как можно трактовать «прямая ответственность программиста — управление памятью» настолько превратно.
Важно понимать как он работает и учитывать при разработке, если можешь им управлять — еще лучше.
Удачи вам с ручной сборкой мусора
Ох уж это поколение графических интефейсов… совсем обленились люди. Следующее будет «удачи вам с расстановкой точек остановки руками» или «удачи вам чтения отладочных логов глазами»?
Понятно :) Вопрос универсальности я не ставил, и не понятно откуда Вы его придумали.
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
Ну давайте посмотрим эволюцию ECMA-262. Let добавили с более адекватным поведением, class добавили. На мой взгляд — двигаются в сторону «как у всех», а поскольку сделали TypeScript, который еще более «как у всех» и webAccembly шустро распихали по основным движкам, видимо не достаточно быстро JS двигается в сторону «как у всех»
И для этого не нужно применять сложные оптимизации, выполняемые senior программистами, окончившими специальные полугодовые курсы oracle/microsoft
Ничего сложного нет. Простая как грабли стратегия — нагадил? убери за собой! Кроме тебя никто не знает какая у тебя стратегия работы с памятью.
По моему мнению, как писавшему код как на С++ так и C#/Java, прямая ответственность программиста — управление памятью, а всякие GC — просто сервис, а у дареного коня всегда с кариес :).
если C# / Java / JS для вас нормальные,
Свои задекларированные возможности исполняют? Это дешевле чем «другой обычный/популярный язык»? значит нормальные.
Я переписал 2 ситемы из категории «опердень» на Гоу с С#. Результат — пиковая нагрузка на проц плюс минус та же, но мозгов сжирает меньше в разы — подтверждается различными бенчмарками и легко объясним. Думаю с java была бы принципиально та же ситуация, ибо вряд ли в .net под виндовз JIT компилятор хуже java.
Мельком глянул описание работы GC «Go 1.4+ Garbage Collection (GC) Plan and Roadmap» — у .Net и Go, разные стратегии работы с памятью. Не удивительно что результаты разные. Если бы задались целью оптимизировать использование памяти в C# — возможностей для оптимизации море.
В распараллеленных выйгрыш по перформансу при переходе на Гоу, надеюсь вы понимаете — колосальный.
Это будет в любом языке нормальном языке.
Не понятно где тут «сильно круче».
Готовый вид это значит что я могу работать со строкой как с отдельным самостоятельным объектом,
В общем-то это на разных слоях объекты Data Transfer Object и Plain Object.
Кто-то должен из понятий базы данных Table & Row & Field сделать Entity + Property.
Просто решите на каком уровне вы хотите с БД работать и все :)
Зачем это делать в рантайме? Вы можете оттранслировать-отанализировать AST в нужный вам проблемноспецифичный IR во время компиляции, а во время выполнения, не знаю, подставить нужный синтаксис запросов, специфичный для вашей базы. Зачем всё в рантайм-то переносить?
В этом и фишка, что:
можно в бизнес-логике строить запросы в процессе работы
на ходу менять базы/источники данных
провайдеры баз/источников данных занимаются трансляцией объектных выражений LinQ из «абстрактного» в «конкретный»
Ваша проблема в том что вы зависли в парадигме «функция обязана возвращать что-то определенное», в JavaScript'e — не обязана (аргумент про «не изучил, но критикую»)
Нюанс в том, что все функции всегда что-то возвращают, но это будет void (С++) или undefined в случае с js.
Некоторые языки программирования такие функции/Function именуют процедурами/Sub и/или предотвращают такие проблемы и вопросы с неоднозначностью поведения еще на этапе компиляции в отличие от «оно само сделает» в случае в JS.
Я имел в виду что вы не можете явно начать тред и явно его грохнуть
В свое время theadpool создавал потоки «по запросу». Но это внутренняя оптимизизация.
API тредпула этого не позволяет,
Так у него другая задача — предварительно созданные thread(s) и их последовательное переиспользование, а не создание каждый раз заново и удаление.
Экономия на времени создания потока, а что вы будете делать с этими потоками и когда — это полностью ваша проблема.
Можете руками такое сделать без особых проблем (руками в массиве поместить с десяток потоков предварительно созданных и периодически дергать их) — производительность будет таже самая.
Технически (на примере C#) асинхронный ввод-вывод, как уже было сказано ниже, реализуется через completion ports и не имеет ничего общего с тредами как таковыми.
Если не считать того, что по умолчанию там используется… threadpool.
А если читать мануалы MS внимательно, что там написано примерно следующее:
1. вы можете создавать потоки руками и вручныю ими управлять, а что бы забрать результат или быть извещены о результатет то подписаться на callback
2. если вам лень заниматься п.1 (ручное управление потоками), используйте threadpool, он предоставляет сервис управленяи потоками и их использования.
3. если вам в лень заниматься п.2 (использовать полуавтоматическое управление потоками), используйте Tasks. Но, если вам свербит в одном месте и хочется какой-то контроль, то можете наваять свой TaskScheduler для «handles the low-level work of queuing tasks onto threads».
и те же task наследованы от IAsyncResult через который работает п1 и п2 :)
Это просто наслаивание сервисных оберток, а внутри старый добрый Thread и Threadpool :)
Лень, двигатель прогресса.
Почему до сих пор тогда нету vbs программистов? У vbs порог тогда вообще никакой по сравнению с js, ибо возможностей больше,
VBS — на нем был сделан в конце 90х начале 200х ASP. Как вспомню тот @#$^$% что творился при отладке, до сих пор в ужас бросает. Возможно MS после этого сделал вменяемый ASP.NET забрав все что можно в контролируемое окружение с нормальным инструментарием. Это было как радуга… как фантастика после VBS для веб разработки. После этого любые «слабая типизация» или «оно само сделает» ничего кроме мата в мыслях не вызвает.
Да, функция это объект), например она может содержать статическое свойство
Объект чего?
Если это некоторый контейнер времени исполнения который можно создать в любое время и присоединить к нему как код так и данные, ну так давайте его и назовем, к примеру, RuntimeContainer.
Если это некоторый выделенный кусок кода со свои функционалом — давайте назовем его, к примеру, function.
А так мутант какой-то :)
Пример неймспейсов
Не очень удачный пример, поскольку пространстов имен это логический контейнер. Грубо говоря это синтаксис, а не исполнение/runtime. А то, что приведено это скорее вложенные классы с эмуляцией «полного имени»
Паттерн Модуль + Фасад. Данные и код хранятся в замыкании, без возможности доступа извне, кроме определенных методов или свойств. Та же инкапсуляция по сути
Вот! Приходится использовать кучу дополнительных примочек и костылей, что бы решить типовую задачу разработки. Т.е нужно вкладывать усилия не в решение бизнес задач клиента, а в решение типовых «нюансов» инструмента.
Если бы это были новые не известные проблемы можно было бы понять. Но это же типовые и давно известные.
Классы это хорошо, но в JS их нет, в место них объекты, другой вообще подход
Это не лучшее оправдание. Приведенные выше примеры понятны и проистекают из архитектуры языка, которая просто не была готова к тем задачам, которые пытаются им решить.
Ничем хорошим это не кончится
JS – прототип-ориентированный язык, а это модель ООП.
Тут выбешивает несколько иное. Функция, которая не «функция», объект который не «объект» и нету четких границ где что находится. Я хочу получить нормальный «контейнер» в котором будут изолированы функции, я хочу безопастное контролируемое мной хранилище данных, и я не хочу, что бы Тот Парень как-то повлиял на мой код или данные.
Вроде много лет назад именно для этих целей и сделали классы и пространства имен.
Как это все назвать? И в JS и как решить эти проблемы, если классы это «плохо»?
Почему Вы полагаете, что Прототип-ориентированный язык это препятсвие для решения этих проблем?
Судя по направлению развития JS начинает быть похожим на другие решения.
А если смотреть в сторону WebAssembly, то похоже JS многих «достал», и наконец решили сделать нормальное решение.
Похоже не сильно себе представляют что ищут и как.
Давайте наймем водителя с такой логикой?
Итак, задачи водителя при найме:
Что такое цикл Карно ?
расчитайте трения качения колес вашей машины ?
Нарисуйте фронт детонации от свечи в двигателях машин ?
Чем отличается двигатель из чугуна, стали, аллюминия, керамики ?
Что такое двигатель внутреннего сгорания, внешнего сгорания ?
Соберите паровую машину из зажигалки зиппо, пружинки от шариковой ручки и корпуса металлического карандаша ?
Ага, не знаешь! Как ты тогда собираешься водить такси или трактор?
Вот как-то же без этого мозгоклюйства решили проблему в остальном мире, и права признают выданные в другой стране, и медицину и еще много чего.
А тут какое-то мерянье професионалов «на вес и в ширину»… Как прием в средневековую гильдию :)
Вы этим пользуетесь каждый день, когда используете, например, ассоциативные массивы или индексы в базах данных
Серьезно? :) а почему именно бинарное дерево?
А давайте сразу все эти индексы?
B-tree indexes
B-tree cluster indexes
Hash cluster indexes
Global and local indexes
Reverse key indexes
Bitmap indexes
Function-based indexes
Domain indexes
потому что они слишком простые чтобы их забыть и вы их начинаете видеть их везде.
Человеку с молотком везде мерещатся гвозди? :)
Сколько раз в жизни Вы реализовали свой индекс для поиска? сколько раз в жизни Вы просчитали цену этого алгоритма и сравнили с другими алгоритмами для всех сценариев? или выбирали из готовых согласно рекомендаций «прозводителя»?
если вы хотя бы один раз в жизни написали руками этот несчастный бинарный поиск.
У меня было пару преподавателей информатики, которые еще с 60-х годов работали на вычислительных машинах (лет 30...35 опыта работы от ламповых шкафов до Intel Pentium). Ни разу не помню, что бы заостряли внимание на бинарных деревьях как на таковых, зато отлично вбили в голову как анализировать алгоритмы и оптимизировать их исходя из поставленных задач и доступных ресурсов. «Этот несчастный бинарный поиск» проходил просто как один многих наглядных примеров. Учили создавать и опимизировать, а не тупо пользовать.
Есть разница между заполнить таблицу умножения и просто уметь умножать :)
Вы требуете «таблицу уможение», а не умения умножать :)
За эту науку им благодарен безмерно, а не за алгоритмы как таковые.
Как работает прототипное наследование и чем оно отличается от классической модели наследования? (По моему мнению, это не особенно полезный вопрос, но многим нравится его задавать.)
Кто-нибудь может привести примеры отличий? Мне в голову приходит только то, что в прототипном наследовании можно добавлять методы динамически
Как по мне, так это похоже на ручную сборку таблицы функций «руками» в момент исполнения, вместо компилятора.
Ни разу не встречал человека забывшего базовые вещи.
Базовые для кого?
Пошел я как-то пообщаться пару лет назад. И спрашивают у меня «а скажите нам, а что такое SOLID для архитектуры ?» Я честно сказал не знаю, потому что этот SOLID у меня ни с чем не ассоциировался, только на переферии сознания мелькнуло «что-то знакомое». Пришел я домой и начал читать что такое SOLID? И где-то минут через 10 вспомнил! Читал я расшифровку этого SOLID лет 5..7 назад, но поскольку эти принципы и так использовались по отдельности и под другими названиями и ничего нового не давало, то в голове просто не запомнилось, а мозг решил не запоминать «мусор».
И вот вопрос: ты не знаешь как проектировать/писать софт или не знаешь как расшифровывается SOLID? Да и сейчас мозг просто отказывается это запоминать.
Я не вижу в этой ситуации ни одной выйгравшей стороны.
Сейчас плодится столько разной фигни делающие весьма схожие вещи, но под разными названиями что мозг просто заполнен всяким шлаком. А если учесть, то у тебя есть еще и текущий проект(ы) со своей предметной областью, то это все превращается в какой-то сюрреализм.
CodeStyle & Design guide определите для проекта и будет вам счастье.
А тут что не так или библиотеки не должны «материться» если вы в них пихаете всякую дрянь? :) Как еще библиотека скажет, что «у вас золотые руки, но от бедер растут потому что....»?
Точно в такой же мере, как и любой другой сервисный инструмент. Есть — хорошо, нету — ну и фиг с ним, сам сделаю.
Не очень понято, как можно трактовать «прямая ответственность программиста — управление памятью» настолько превратно.
Важно понимать как он работает и учитывать при разработке, если можешь им управлять — еще лучше.
Ох уж это поколение графических интефейсов… совсем обленились люди. Следующее будет «удачи вам с расстановкой точек остановки руками» или «удачи вам чтения отладочных логов глазами»?
Ну давайте посмотрим эволюцию ECMA-262. Let добавили с более адекватным поведением, class добавили. На мой взгляд — двигаются в сторону «как у всех», а поскольку сделали TypeScript, который еще более «как у всех» и webAccembly шустро распихали по основным движкам, видимо не достаточно быстро JS двигается в сторону «как у всех»
Ничего сложного нет. Простая как грабли стратегия — нагадил? убери за собой! Кроме тебя никто не знает какая у тебя стратегия работы с памятью.
По моему мнению, как писавшему код как на С++ так и C#/Java, прямая ответственность программиста — управление памятью, а всякие GC — просто сервис, а у дареного коня всегда с кариес :).
Свои задекларированные возможности исполняют? Это дешевле чем «другой обычный/популярный язык»? значит нормальные.
Мельком глянул описание работы GC «Go 1.4+ Garbage Collection (GC) Plan and Roadmap» — у .Net и Go, разные стратегии работы с памятью. Не удивительно что результаты разные. Если бы задались целью оптимизировать использование памяти в C# — возможностей для оптимизации море.
Это будет в любом языке нормальном языке.
Не понятно где тут «сильно круче».
Это откуда такой пессимимзм?
В общем-то это на разных слоях объекты Data Transfer Object и Plain Object.
Кто-то должен из понятий базы данных Table & Row & Field сделать Entity + Property.
Просто решите на каком уровне вы хотите с БД работать и все :)
В этом и фишка, что:
Обычно есть некторые механизмы оптимизации.
Нюанс в том, что все функции всегда что-то возвращают, но это будет void (С++) или undefined в случае с js.
Некоторые языки программирования такие функции/Function именуют процедурами/Sub и/или предотвращают такие проблемы и вопросы с неоднозначностью поведения еще на этапе компиляции в отличие от «оно само сделает» в случае в JS.
В свое время theadpool создавал потоки «по запросу». Но это внутренняя оптимизизация.
Так у него другая задача — предварительно созданные thread(s) и их последовательное переиспользование, а не создание каждый раз заново и удаление.
Экономия на времени создания потока, а что вы будете делать с этими потоками и когда — это полностью ваша проблема.
Можете руками такое сделать без особых проблем (руками в массиве поместить с десяток потоков предварительно созданных и периодически дергать их) — производительность будет таже самая.
Если не считать того, что по умолчанию там используется… threadpool.
А если читать мануалы MS внимательно, что там написано примерно следующее:
1. вы можете создавать потоки руками и вручныю ими управлять, а что бы забрать результат или быть извещены о результатет то подписаться на callback
2. если вам лень заниматься п.1 (ручное управление потоками), используйте threadpool, он предоставляет сервис управленяи потоками и их использования.
3. если вам в лень заниматься п.2 (использовать полуавтоматическое управление потоками), используйте Tasks. Но, если вам свербит в одном месте и хочется какой-то контроль, то можете наваять свой TaskScheduler для «handles the low-level work of queuing tasks onto threads».
и те же task наследованы от IAsyncResult через который работает п1 и п2 :)
Это просто наслаивание сервисных оберток, а внутри старый добрый Thread и Threadpool :)
Лень, двигатель прогресса.
Серьезно? Т.е там нету работы в разных потоках, нету точек синхронизации? Магия ?!
VBS — на нем был сделан в конце 90х начале 200х ASP. Как вспомню тот @#$^$% что творился при отладке, до сих пор в ужас бросает. Возможно MS после этого сделал вменяемый ASP.NET забрав все что можно в контролируемое окружение с нормальным инструментарием. Это было как радуга… как фантастика после VBS для веб разработки. После этого любые «слабая типизация» или «оно само сделает» ничего кроме мата в мыслях не вызвает.
Объект чего?
Если это некоторый контейнер времени исполнения который можно создать в любое время и присоединить к нему как код так и данные, ну так давайте его и назовем, к примеру, RuntimeContainer.
Если это некоторый выделенный кусок кода со свои функционалом — давайте назовем его, к примеру, function.
А так мутант какой-то :)
Не очень удачный пример, поскольку пространстов имен это логический контейнер. Грубо говоря это синтаксис, а не исполнение/runtime. А то, что приведено это скорее вложенные классы с эмуляцией «полного имени»
Вот! Приходится использовать кучу дополнительных примочек и костылей, что бы решить типовую задачу разработки. Т.е нужно вкладывать усилия не в решение бизнес задач клиента, а в решение типовых «нюансов» инструмента.
Если бы это были новые не известные проблемы можно было бы понять. Но это же типовые и давно известные.
Это не лучшее оправдание. Приведенные выше примеры понятны и проистекают из архитектуры языка, которая просто не была готова к тем задачам, которые пытаются им решить.
Ничем хорошим это не кончится
Тут выбешивает несколько иное. Функция, которая не «функция», объект который не «объект» и нету четких границ где что находится. Я хочу получить нормальный «контейнер» в котором будут изолированы функции, я хочу безопастное контролируемое мной хранилище данных, и я не хочу, что бы Тот Парень как-то повлиял на мой код или данные.
Вроде много лет назад именно для этих целей и сделали классы и пространства имен.
Как это все назвать? И в JS и как решить эти проблемы, если классы это «плохо»?
Почему Вы полагаете, что Прототип-ориентированный язык это препятсвие для решения этих проблем?
А если смотреть в сторону WebAssembly, то похоже JS многих «достал», и наконец решили сделать нормальное решение.
Давайте наймем водителя с такой логикой?
Итак, задачи водителя при найме:
Ага, не знаешь! Как ты тогда собираешься водить такси или трактор?
Вот как-то же без этого мозгоклюйства решили проблему в остальном мире, и права признают выданные в другой стране, и медицину и еще много чего.
А тут какое-то мерянье професионалов «на вес и в ширину»… Как прием в средневековую гильдию :)
Серьезно? :) а почему именно бинарное дерево?
А давайте сразу все эти индексы?
Человеку с молотком везде мерещатся гвозди? :)
Сколько раз в жизни Вы реализовали свой индекс для поиска? сколько раз в жизни Вы просчитали цену этого алгоритма и сравнили с другими алгоритмами для всех сценариев? или выбирали из готовых согласно рекомендаций «прозводителя»?
У меня было пару преподавателей информатики, которые еще с 60-х годов работали на вычислительных машинах (лет 30...35 опыта работы от ламповых шкафов до Intel Pentium). Ни разу не помню, что бы заостряли внимание на бинарных деревьях как на таковых, зато отлично вбили в голову как анализировать алгоритмы и оптимизировать их исходя из поставленных задач и доступных ресурсов. «Этот несчастный бинарный поиск» проходил просто как один многих наглядных примеров. Учили создавать и опимизировать, а не тупо пользовать.
Есть разница между заполнить таблицу умножения и просто уметь умножать :)
Вы требуете «таблицу уможение», а не умения умножать :)
За эту науку им благодарен безмерно, а не за алгоритмы как таковые.
Как по мне, так это похоже на ручную сборку таблицы функций «руками» в момент исполнения, вместо компилятора.
Базовые для кого?
Пошел я как-то пообщаться пару лет назад. И спрашивают у меня «а скажите нам, а что такое SOLID для архитектуры ?» Я честно сказал не знаю, потому что этот SOLID у меня ни с чем не ассоциировался, только на переферии сознания мелькнуло «что-то знакомое». Пришел я домой и начал читать что такое SOLID? И где-то минут через 10 вспомнил! Читал я расшифровку этого SOLID лет 5..7 назад, но поскольку эти принципы и так использовались по отдельности и под другими названиями и ничего нового не давало, то в голове просто не запомнилось, а мозг решил не запоминать «мусор».
И вот вопрос: ты не знаешь как проектировать/писать софт или не знаешь как расшифровывается SOLID? Да и сейчас мозг просто отказывается это запоминать.
Я не вижу в этой ситуации ни одной выйгравшей стороны.
Сейчас плодится столько разной фигни делающие весьма схожие вещи, но под разными названиями что мозг просто заполнен всяким шлаком. А если учесть, то у тебя есть еще и текущий проект(ы) со своей предметной областью, то это все превращается в какой-то сюрреализм.