Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

V>>>Шаблоны — это вообще не про оптимизацию бинарника.
V>>>Шаблоны — они про автоматизацию разработки.

S>> Во как. Оказывается на основании шаблонов компилятор не генерит исходный код используя побочный эффект от перегрузки операторов?

V>Мде-с.
V>Я с трудом себе представляю всю палитру флуктуаций разума, такскать, чтобы умудриться на моё процитированное породить подобный ответ. ))

То есть компилятор не занимается кодогенерацией при специализации шаблона?

По твоему ответу получается, что Дженерики лучше шаблонов.

Здравствуйте, vdimas, Вы писали:

V>>>В рамках JS не изобретено ни одной идиомы.
G>>Ты не знаешь JS.

V>Я знаю его намного лучше тебя.

В прошлый раз мы выяснили, что ты его знаешь на уровне синтаксиса. Ты хоть понял фиксы в твоём коде ?

Здравствуйте, vdimas, Вы писали:

G>>Ты утверждал что v8 не развивается, в чем ошибся.

V>Тебе стоит опровергать мои утверждения относительно того, что именно "развивается" в v8.
V>Но предметность тебе не даётся, вестимо.

Гугл решил тебе насолить и влупить мега-фичу — оптимизатор Джаваскрипта:

The new compiler pipeline uses the Ignition interpreter and Turbofan compiler to execute all JavaScript (in place of the classic pipeline which consisted of the FullCodegen and Crankshaft compilers)

https://v8project.blogspot.com.by/2017/02/help-us-test-future-of-v8.html
https://v8project.blogspot.com.by/2016/12/v8-release-56.html

И оптимизации асинхронщины
https://v8project.blogspot.com.by/2017/02/v8-release-57.html

Оптимизации памяти:
https://v8project.blogspot.com.by/2017/02/one-small-step-for-chrome-one-giant.html

Регэкспы:
https://v8project.blogspot.com.by/2017/01/speeding-up-v8-regular-expressions.html

Кроме того — DOM и JS кучи будут объединяться. Собственно для этого и нужен новый оптимизатор, что бы JS кушал поменьше памяти.

Из самого последнего, по мелочи, — for-in оптимизации.

Здравствуйте, Kerk, Вы писали:

K>Если честно, никак не пойму, почему оно не станет очередным сильверлайтом. Кто-нибудь может пояснить чем wasm отличается от множества нативных и не очень технологий, которые пытались встраивать в браузеры в предыдущие 20 лет?

1. Хотя бы потому, что это не проект какой-то одной компании, а результат договорённости всех основных игроков. Так что это будет не какой-то сторонний плагин, а неотъемлемая часть браузеров, причём сразу всех ведущих. Да и сам стандарт является полностью открытым с самого рождения.
2. На данной платформе теоретически поддерживаются любые языки, без ограничений. Пока правда есть инструмент только для C++ и планируется для Rust, но уже одно это автоматически добавляет огромную орду всяческих скриптовых языков написанных на C/C++.
3. По быстродействию данное решение будет заметно лучше JVM/.Net/Flash, не сильно уступая нативному коду, т.к. по сути основано на LLVM. Я кстати тут уже немного поигрался с тестами http://rsdn.org/forum/flame.comp/6729734.1

Автор: alex_public
Дата: 20.03.17

, так что это не просто предположения. Конечно были ещё ActiveX с нативным уровнем производительности, но они были небезопасные, поддерживаемые одним браузером и требующие определённую архитектуру процессора.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

V>>>node.js помимо всего прочего, что операции ввода-вывода для каждого отдельного файлового хендла будут привязаны к одному и тому же потоку.
G>>Ты не в курсе что node однопоточный?

V>Я ХЗ, расписывать ли тебе работу реактора для ситуации, когда файловый хендл привязан только к одному обслуживающему потоку или сразу к нескольким.
Кто о чем, а вшивый о бане...
Ты пытаешься свою теорию воткнуть туда, где она не нужна.


V>Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.
Завершаться может когда угодно, а коллбеки в JS вызываются строго последовательно. Если же ты попробуешь иницииоровать две асинхронные операции с одним ресурсом в одно время, о получишь или ошибку или одна выполнится после другой. Так что состояние гонки в js ты не получишь никаким образом.

V>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
Нет. Никакой ввод-вывод в других потоках не исполняется. Есть один поток выполнения, все хендлы принадлежат ему, весь ввод вывод инициируется в нем, все коллбеки выполняются тоже в нем.


V>Пока что ты показываешь непонимание вообще ничего.
V>Как и 8 лет назад.
V>Причем, я твоё непонимание показываю в каждом сообщении, а ты всё обещал показать моё — но так и не смог.
Чувак, ты о чем? Ты даже про модульность в JS не в курсе. Это проблема решенная 5 лет назад. Ты продолжаешь доказывать, что модульности нет. О чем с тобой еще говорить?
Если ты хочешь мою личность обсудить, то ты не туда пришел.


V>>>С++ бъет по рукам за ошибки, вызванные непониманием происходящего.
G>>И большинству это не помогает. Люди находят workaround и пользуются им всю жизнь, так и продолжая не понимать суть.
V>Ну это про маньяков каких нить. ))
Это про подавляющее большинство программистов.

V>Люди просто уходят на другие технологии, если им неохота разбираться в подробностях.
Люди всегда идут по пути наименьшего сопротивления. Это свойство мозга человека. Пока воркэраунд дает приемлемый результат многие будут продолжать пользоваться им, не вникая в суть процессов.
Причем в C++ такая ситуация ярко видна. Затраты на изучение большие, а выхлоп маленький. Твое знание


G>>Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
V>Ссылка?
http://rsdn.org/forum/cpp/6722750.flat

Автор: Jumangee
Дата: 11.03.17

V>Половина спрашивающих на форуме С++ — это студенты или вчерашние студенты.
Это как раз показывает средний уровень.


V>>>Я уже всё сказал:
V>>>

V>>>Я так думаю, что программист с ростом должен уметь решать всё более сложные задачи.

G>>Как это связано с языками? Сложные задачи могут быть на любом языке.

V>Не на любом.
Докажи.

V>Если для node.js на C++ не напишешь АПИ на некую нейтивную функциональность, то вот уже и нет решения на JS.
Нейтивная функциональность в области, где работает nodejs нужна чуть реже, чем никогда.
Да и прокидывание нейтивной функциональности в NodeJS сложной задачей не является от слова совсем.

V>JS как язык внутри пуст как абстрактное зеро.
Что значит "внутри пуст"? Какой яызк внутри непуст?

V>Вся его полезная функциональность поставляется нейтивным хостом или нейтивными же "обертками"-библиотеками над имеющимся плюсовым кодом.
У лобого яызка так. С++ тоже внутри пуст, не дёргая API ОС он вообще ничего сделать не может.


V>Поэтому, на JS сейчас пишут медленно и отлаживаются долго.
На JS пишут и отлаживают быстрее, чем на C++

V>И чем больше по размерам проект, тем меньше продуктивность.
Везде так, как бы тебе не казалось обратное.



G>>Вполне может оказаться так, что сложная задача на одном языке в другом языке становится примитивной. Поэтому и надо повышать продуктивность и изучать более мощные языки.
V>А зачем тебе такие языки, которые делают задачи сложными или нерешаемыми?
То есть C++надо изучать? ок.

V>Система типов того же C++ позволяет описывать код, типа твоего Excel на JS типобезопасно и при этом так же выразительно.
И что?

V>Тут нужен лишь некий eval для формул.
Всего-то

Этот eval будет на два порядка (в сотни раз) сложнее, чем типа-безопасный код.
Ты превратил таким образом задачу из примитивной в очень сложную.

V>Сам-то eval всегда нейтивный, разумеется, даже в JS. ))

V>Тут вся фишка типобезопасности в том, что она обеспечивает отсутствие "эффекта засорения" проекта хелперами. Всевозможные хелперы не конфликтуют друг с другом, в отличие от библиотек JS, которые часто портят друг другу жизнь, у которых хромает версионность и такое понятия как "детерминированное АПИ" отсутствует как класс.


V>Верно, но ты же пытаешься превратить разработку в конвейер, а не в процесс роботизации.
Я?

V>Т.е. ты настаиваешь на навыках шустрого использования "имеющегося" а не разработки нового.
А при чем тут конвейер? Сейчас любая разработка — сборка из готовых блоков. Важно уметь находить блоки и соединять друг с другом. Изредка бывает готовый блок настолько не подходит, что проще переписать, чем пытаться соединить с другими.


V>Я вижу, что средний JS программист может решить только те задачи, под которые есть соответствующий фреймворк/библиотеки.
V>Точно так же когда-то высмеивали дельфистов, кста.
Только разница в том, что для делфи не было (нормальны) компонентов, а на js есть все, что может пригодиться в веб-разработке.
Поэтому можно смеяться сколько влезет, а на JS все равно собрать решение выйдет быстрее.



G>>Пока языки имеют примерно одинаковые возможности, то разница заключается в основном в библиотеках.
V>Верно.
V>Но еще играет рояль возможность дописать отсутствующую функциональность при надобности.
V>И тут "примерно одинаковые возможности" порой превращаются в "резко разные".
Как раз в области "дописать чето" все языки почти равны.


G>>Потом появился linq и java с С++ начали отсасывать.

V>Linq в основном нужен только там, где "формочки".
V>Потому что прочитать из базы, взять итоги, отсортировать, отобразить.
V>Вот тебе класс примитивных операций над множествами для формошлёпства или веб-морды.
В этом и заключается большая часть код корпоративных приложений.



G>>Потом то же самое произошло с async\await. Сейчас появился C# 7 с огромной кучей новых фишек для продуктивности. Это конечно не революции типа linq и async, но тоже двигает язык вперёд.
V>Сегодня язык двигает вперёд больше .Net Core или .Net Native.
Каким образом? Как вообще фреймворк развивать язык? Наоборот я еще могу представить.


V>>>Собсно, на сегодня это даже не сравнимо, бо в скорости написания кода C# уже резко отстаёт, хотя еще в 2005-м резко обгонял плюсы.
G>>Да конечно Ты наверное и C# последний раз году в 2005 видел.

V>Нет, это ты смотрел на C++ в последний раз в 1998-м.
Я в курсе современного C++, даже мелочи писал на нем.

V>А я на шарпе упражняюсь регулярно.
Еще стоило бы JS подтянуть



V>В общем, как только объем доступных библиотек для плюсов догнал жабку и шарп, так сразу же на плюсах всё стало намного быстрее и проще.
"Всё" это что? У C++ до сих пор огромные пробелы в библиотеках, и каждый фреймворк затыкает их по-своему.
Какой сегодня "стандартный" способ делать http запрос? Или сериализацию\десериализацию json? А есть "стандартный" абстрактный API для баз данных или под каждую СУБД надо лобзиком выпиливать свой код? А что у C++ с асинхронным кодом? И как на нем сделать веб-приложение?

Если для тебя наличие конкурентных коллекций в составе стандартной библиотеки ставит на один уровень её с возможностями .NET FW, то у тебя "Всё! — это очень маленькая часть того, что люди делают вообще.

V>Тут несравнимо от слова совсем, просто ты не в теме.
Конечно, я настолько простыми вещами даже не занимаюсь.

V>Там, где мне на шарповом проекте приходилось писать кучу утилит, хелперов и т.д., там на плюсах объем этих хелперов, во-первых, на порядки меньше (исходный код не в пример более повторно применим), во-вторых, сами эти хелперы пишутся быстрее и шире применимы.
Я не видел хелперов уже несколько лет.


V>Я регулярно смотрю рефлектором или через dotPeek устройство всяких дотнетных библиотек, особенно которые пытаются "окучить" некие технологи — это просто какая-то ж-па. Там реально МНОГО кода на пустом месте. Ну как "на пустом". Он там реально нужен, в этом и заключается звиздец. В случае С++ 90% такого кода НЕ нужно.
Ну так приведи пример, на слово тебе верить чтоли?

V>Посмотри ради любопытства асинхронный ввод/вывод на сокетах, класс Task и прочее — это же жесть, как она есть.
V>Горы кода, чтобы выразить простейшие вещи.
У тебя синдром самого умного.
Те кто писали Task гораздо умнее тебя и проектировали классы с учетом вариантов использования, которые тебе в голову никогда не придут. Так что я бы на твоем месте не был настолько самоуверен.
Ну и для того, чтобы тебе не быть голословным приведи реализацию Task и укажи что ты считаешь лишним.


V>В общем, как ни крути, но на C# на одну и ту же функциональность надо больше исходного кода больше траха.
Кажется я уже рассказывал тебе эту историю.
На 5 курсе надо было делать матмодели для уже не помню каких расчетов. Матрицы складывать и умножать.
Я начал делать на C#. Мой одногрупник, крутой C++ программист, недавно в яндекс устроился кстати, начал писать на C++.
За пару дней я сделал всю математику и визуализацию расчетов, а он только трахался с математикой над матрицами в этом время.


V>Он показывает свою "силу" только в случае уже готовой некоей функциональности, когда "кто-то другой" уже сделал.
Еще раз напомню, что современное программирование это сборка из готовых кусков.

V>А если эту функциональность надо писать самому — то это застрелиться.
V>Современные ORM фреймворки для C++ в строках кода уже сильно меньше, чем здешний BLT.
Ага, ноль строк. Потому что нет ни одного ORM, сравнимого с linq2db.

G>>Кстати недавно написал небольшой код на C# и .NET Core, заняло полдня примерно. Чувак решил переписать на C++ и через неделю бросил.
V>Я и на шарпе полно слабых программистов знаю, и?
А кто сказал что он слабый программист?




V>>>Просто посмотри на вот эту библиотеку: http://www.rsdn.org/forum/prj.codejam
V>Эту библиотеку пишут наши .Net-топы с сайта прямо сейчас.
И что? Пишут потому что им хочется, все должны использовать после этого?

G>>при появлении достаточной массы кода на C# команда разработчиков начала тупо смотреть какой код люди пишут и повышать продуктивность написания такого кода.
V>А чего же у самих так много кода на пустом месте?
Где именно?

V>Где же живет та самая "продуктивность"? ))
Продуктивность живет не в Фреймворке, а там где его используют.

V>Почему WPF делали 5 лет и он так и не взлетел (заранее рекламировали дотнетный Avalon как GUI-систему для виндов).
V>Зато его аналог на плюсах выкатили за полтора года и оно летает на виндах от 8 и выше?
Политические моменты внутри МС. Те, кто занимались windows очень не хотели пускать туда тех, кто занимался .NET. Поэтому в Windows Server куча .NET утилит на WPF, а в Windows 8-10 ни одной.

V>Причем, сделали его меньшим числом разработчиков (примерно в 5 раз меньше, чем работало над WPF)?
Во-первых откуда дровишки? Во вторых вовсе неудивительно что на переписывание готового отлаженного кода требуется меньше ресурсов, чем на написание с нуля.

V>Тем самым вчистую разбив всевозможные мифы относительно ужасности нейтивной разработки?
В твоей голове, ага.

V>За что и погнали, собсно, Великого Липперта ссаными тряпками.
Там же чистая политика, технологии вообще не при чем.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>>>Поэтому проще написать JS и дергать api из браузера, чем писать серверный код.
V>>>Кошмар ))
G>>Таковы реалии enterprise разработки.

V>Это реалии "впаривания".
V>Подобные задачи на современной 1С решаются лучше и надёжней.

Далеко не все решается в 1С. Далеко не все, что решается в 1С делается достаточно просто и поддерживаемым образом.

G>>А есть еще всякие облачные сервисы, где у тебя нет даже технической возможности написать серверный код.
V>Ага, с одним "но" — в гугловых облачных серверах не предоставляют node.js.
Помоему все крупные игроки кроме гугла предоставляют.

V>Зато MS предоставляет. Забавно, не правда ли? ))
V>Видишь, как много ты рассказал о себе одной фразой.
Я тебя расстрою, это ты о себе много рассказал одной фразой.
Но не сейчас, а сильно раньше.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, vdimas, Вы писали:

V>>>Перегрузка операторов — это весьма популярный приём в С++, т.е. фича востребованная, при её наличии.
G>>Можешь показать примеры перегрузки операторов, кроме случаев:
G>>1) Математических объектов, когда перегружаются операторы для сложения\умножения векторов\матриц\итд
V>Это изкаробки был основной кейз. ))
Это by default вариант использования перегрузки операторов. Но в других языках этот кейс редко встречается. Все числодробилки обычно на C++ и пишутся. Видел даже исследования на эту тему, ссылку сходу не нашел.


G>>2) Перегрузки оператора ->, ()
V>И это тоже. Смарт-поинтеры и функторы.
V>В этом смысле в дотнете всё печально — или пиши a.b.c.d.TargetMethod, или пиши делегирующий код на каждом уровне.
Это чисто C++ костыль, в других языках не нужен.

G>>3) Перегрузки >> и << для потоков
V>Для чего угодно, для сериализации, форматирования и т.д.
Зачем нужна перегрузка для социализации и форматирования?

G>>Я хочу понять реальные кейсы полезного использования.
V>Парсеры, ленивые комбинаторы, мета-вычисления.
V>Сложить два своих "future", например — получить их комбинацию и т.д.
Ты конкретный пример привести можешь? Складывание двух future — плохая идея от слова совсем.

Не надо приводить примеры в духе "пишу потому что могу". Ты же говоришь что перегрузка операторов — фича востребованная, приведи примеры кейсов, где она действительно востребованная за пределами C++.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

V>>>TS был доработан до "понимания" AtScript.
G>>Ты подробнее вопрос изучи для начала.
G>>В AtScript были аннотации. В ES не было аннотаций, предложение было на ранней стадии. В TS согласились добавить аннотации в формате AtScript пораньше, чтобы разработка Angular2 велась на TS. Когда в стандарте ES проработали аннотации, то в TS и Angular2 стали использоваться аннотации ES.

V>Аннотация там одного и того же формата — через ':'.
Ты думаешь стандарт определяет только синтаксис?


V>Более того, основу W3C составляют представители MS, Гугла и Мозиллы, где последние де-факто являются подразделением Гугла с 2011-го года.
V>Поэтому, эти ребята де-факто порешали м/у собой как и что.
V>И порешали они так, что TS стал понимать код AtScript.
Ты все время думаешь, что корпорация в 100 000 человек это такой однородный организм, который согласовано принимает решения.
На практике люди, сидящие в соседних комнатах могут заниматься противоположными вещами, даже в рамках одних и тех же технологий.
Вообще не факт, что те, кто занимались angular имеют хоть какоето отношение к тем, кто в комитете.


V>Забегал...
V>Ну побегай.
Если сливаешься, то не делай это так "оригинально". Никто не оценит.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

V>>>iOS без натяжки хардкорно нейтивный.
G>>Я чето неточно написал. На iOS два языка, нативный Objective-C и вполне себе managed swift.

_>Теперь язык работающий на подсчёте ссылок называется managed? ) Как интересно то... )))

Это во многом философский вопрос.
Как по мне managed-язык это тот в котором временем жизни объектов управляет "среда". Это может быть отдельный "рантайм" в виде GC, а могут быть и правила компилятора, которые в нужные места втыкают вызовы. Самое главное что это происходит неявно для программиста, снимая с программиста заботу об этом.

Swift вполне себе managed и подсчет ссылок от программиста полностью скрыт, хотя на уровень языка выведены "рычаги" для управления скрытым механизмом.
В этом случае если создатели решат вместо подсчета ссылок сделать GC или прикрутят мощный escape-анализ для размещения объектов на стеке, то с точки зрения кода ничего не изменится.

Обратный пример — если .NET Native переведут на подсчет ссылок, то C# не станет unmanaged языком.

Здравствуйте, gandjustas, Вы писали:

G>Ты пытаешься свою теорию воткнуть туда, где она не нужна.

Т.е. ты по ссылке не ходил?
А там вполне конкретная задача разбиралась.


V>>Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.
G>Завершаться может когда угодно, а коллбеки в JS вызываются строго последовательно. Если же ты попробуешь иницииоровать две асинхронные операции с одним ресурсом в одно время, о получишь или ошибку или одна выполнится после другой. Так что состояние гонки в js ты не получишь никаким образом.

Так вот, разбиралась задача чтения из файла в случае асинхронщины.
У коллеги получалось так, что колбэки от асинхронных операций приходили не в той последовательности, в какой инициировались.
И это нормально для того же overlapped io в виндах, когда мы инициируем более одной асинхронной операции над хендлом, обслуживаемым через IOCP на пуле потоков.

Так вот, к счастью (или нет, ХЗ), но node.js умеет обслуживать один хендл только из одного потока.
Поэтому моя доработка кода коллеги свелась к тому, чтобы разные асинхронные операции использовали общий хендл файла, а не каждый свой при shared-режиме открытия файла.

Вот тебе вполне конкретная задача, где знания о потоковой модели оказались важны.


V>>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
G>Нет. Никакой ввод-вывод в других потоках не исполняется.

Боже, какое нубство. )))


G>Есть один поток выполнения

Есть поток выполнения колбэков одного JS-скрипта.


G>все хендлы принадлежат ему, весь ввод вывод инициируется в нем, все коллбеки выполняются тоже в нем.

Из потоков io в очередь потока JS-интерпретатора вставляются колбэки.
Посмотри исходник, там не сложно — каждая структура, привязанная к хендлу, содержит ссылку на т.н. "контекст исполнения".
Вот в очередь к этому контексту исполнения и копируются колбэки из других потоков.


V>>Причем, я твоё непонимание показываю в каждом сообщении, а ты всё обещал показать моё — но так и не смог.
G>Чувак, ты о чем? Ты даже про модульность в JS не в курсе. Это проблема решенная 5 лет назад. Ты продолжаешь доказывать, что модульности нет. О чем с тобой еще говорить?

В JS модульности нет и не спорь, бо это дилетанство как оно есть.
Потому что я хорошо знаю, как эмулируется модульность в библиотеках JS — этот трюк прост, как и способы его обхода (даже случайного).
Т.е. из-за ошибки программиста в стороннем модуле вся эта "модульность" может улететь к чертям собачьим.

В JS есть некие соглашения о том, как совместными усилиями разработчиков "модулей" не гадить друг другу в пространство имён.
Но "соглашения" — не есть модульность.


G>Если ты хочешь мою личность обсудить, то ты не туда пришел.

Вместо аргументов ты начал раскидываться обвинениями в ошибках, не умея даже эти ошибки показать.


G>>>И большинству это не помогает. Люди находят workaround и пользуются им всю жизнь, так и продолжая не понимать суть.
V>>Ну это про маньяков каких нить. ))
G>Это про подавляющее большинство программистов.

По себе других не судят.


G>>>Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
V>>Ссылка?
G>http://rsdn.org/forum/cpp/6722750.flat

Автор: Jumangee
Дата: 11.03.17

Явно студент.


V>>Половина спрашивающих на форуме С++ — это студенты или вчерашние студенты.
G>Это как раз показывает средний уровень.

Средний уровень спрашивающих?


V>>>>Я уже всё сказал:
V>>>>

V>>>>Я так думаю, что программист с ростом должен уметь решать всё более сложные задачи.

G>>>Как это связано с языками? Сложные задачи могут быть на любом языке.

V>>Не на любом.
G>Докажи.

V>>Если для node.js на C++ не напишешь АПИ на некую нейтивную функциональность, то вот уже и нет решения на JS.
G>Нейтивная функциональность в области, где работает nodejs нужна чуть реже, чем никогда.

Я тебя расстрою — почти вся функциональность node.js нейтивная.
Я имею ввиду основные его JS-либы.
Это всё обертки.


G>Да и прокидывание нейтивной функциональности в NodeJS сложной задачей не является от слова совсем.

Тем не менее, для прокидывания такой функциональности надо быть нейтивным спецом явно посерьезнее, чем спрашивающий на форуме по ссылке.
Получается, ты сам себе противоречишь. ))


V>>JS как язык внутри пуст как абстрактное зеро.
G>Что значит "внутри пуст"? Какой яызк внутри непуст?

С++, C#.
Оба умеют работать с АПИ ОС, т.е. оба могут реализовать любую востребованную функциональность.


V>>Вся его полезная функциональность поставляется нейтивным хостом или нейтивными же "обертками"-библиотеками над имеющимся плюсовым кодом.
G>У лобого яызка так. С++ тоже внутри пуст, не дёргая API ОС он вообще ничего сделать не может.

Может и делает. Например, в драйверах обращается к специальным участкам отображенной на DMA памяти, пишет в порты ввода-вывода.
Ты это и сам должен был знать, просто запамятовал в пылу спора, не? ))


V>>Поэтому, на JS сейчас пишут медленно и отлаживаются долго.
G> На JS пишут и отлаживают быстрее, чем на C++

Это уже сильно устаревшая информация.


V>>И чем больше по размерам проект, тем меньше продуктивность.
G>Везде так, как бы тебе не казалось обратное.

На проектах С++ и C# это ровно наоборот. Чем больше накапливается хелперов, чем более высокоуровневой получается "платформа" конкретного приложения, тем выразительней получаетсяя целевой код и тем проще его поддерживать.

Сам сижу на большом нейтивном проекте уже несколько лет и вижу, что его с каждым годом всё проще развивать, по мере накопления собственных библиотек. Потому что, повторюсь, в строго-типизированной среде не происходит "засорения" пространства имён, не происходит засорения перегруженных сигнатур ф-ий и т.д. А в JS можно убить любую ф-ию через создание одноимённой переменной. Или просто переопределить уже имеющуюся и знать никто не будет. ))

И я не утверждаю, что нет ср-в борьбы с этим — вот, эмуляция модульности, к примеру.
Но я вижу, как легко программисты ломают все эти сугубо вербальные гарантии.
Не специально ломают, ес-но, в этом и проблема.

Здравствуйте, gandjustas, Вы писали:

G>Это во многом философский вопрос.
G>Как по мне managed-язык это тот в котором временем жизни объектов управляет "среда". Это может быть отдельный "рантайм" в виде GC, а могут быть и правила компилятора, которые в нужные места втыкают вызовы. Самое главное что это происходит неявно для программиста, снимая с программиста заботу об этом.

Не останавливайся на достигнутом!
Пусть тогда обычная библиотека подсчёта ссылок — это уже managed:
(нарисовал только что)

    template<typename T>
    struct Box : public T, public virtual RefCountedObjectMT
    {
        template<class ...Args>
        Box(Args ...args) : T(args...) {}
    };

    template<typename T>
    class MakeManaged {
        typedef MakeManaged<T> StrongRef;
        typedef Box<T> * WeakRef;
    public:
        MakeManaged(WeakRef obj) : strong_(obj) {}

        operator WeakRef() { return strong_.get(); }

        template<class ...Args>
        static StrongRef create(Args ...args) {
            return new Box<T>(args...);
        }

    private:
        public boost::intrusive_ptr<Box<T>> strong_;
    };

G>Swift вполне себе managed и подсчет ссылок от программиста полностью скрыт

Ну вот я тестирую показанную "библиотеку":

    struct MyNativeType {
        NativeType(int x, int y) : i_(x + y) {}
        int i_;
    };

    typedef MakeManaged<MyNativeType> MyManagedType; // strong ref
    typedef MyManagedType::WeakRef MyWeakRefType;   // weak ref

    void test() {
        auto strongRef = MyManagedType::create(42, 43);
        std::cout << tmp->i_ << std::endl;
        auto weakRef1 = tmp.weak(); 
        MyWeakRefType weakRef2 = tmp;
    }

Ва-у-у-у...
От программиста всё "скрыто". ))


G>В этом случае если создатели решат вместо подсчета ссылок сделать GC или прикрутят мощный escape-анализ для размещения объектов на стеке, то с точки зрения кода ничего не изменится.

В моём случае аналогично — подменю тонкости объекта Box и с точки зрения зависимого кода ничего не изменится.


G>Обратный пример — если .NET Native переведут на подсчет ссылок, то C# не станет unmanaged языком.

Не переведут.
Без идиомы совместной работы "слабых" и "сильных" ссылок рефкаунтинг не живёт.
В Swift эта идиома есть изкаробки, ес-но и обязательна к применению через ключевое слово weak.

Здравствуйте, vdimas, Вы писали:

V>Сам сижу на большом нейтивном проекте уже несколько лет и вижу, что его с каждым годом всё проще развивать, по мере накопления собственных библиотек. Потому что, повторюсь, в строго-типизированной среде не происходит "засорения" пространства имён, не происходит засорения перегруженных сигнатур ф-ий и т.д. А в JS можно убить любую ф-ию через создание одноимённой переменной. Или просто переопределить уже имеющуюся и знать никто не будет. ))

Ты TS каким языком считаешь? Там та же модульность, пространства имен, та же типизация.
А Js выступает как ассемблер.
C# кстати не является строго- типизированным. А те же динамики делают язык гибким без лишних оберток.

Ты кстати Dart расхваливал, а он ни чем не лучше TS. При этом тоже компилируется в JS.

Здравствуйте, gandjustas, Вы писали:

_>>Теперь язык работающий на подсчёте ссылок называется managed? ) Как интересно то... )))
G>Это во многом философский вопрос.
G>Как по мне managed-язык это тот в котором временем жизни объектов управляет "среда". Это может быть отдельный "рантайм" в виде GC, а могут быть и правила компилятора, которые в нужные места втыкают вызовы. Самое главное что это происходит неявно для программиста, снимая с программиста заботу об этом.

Правильно ли я понимаю, что если я напишу на C++ программу, в которой не будет ни одного явного new/delete, то это будет означать, что программа написана на управляемом языке? )

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Ты пытаешься свою теорию воткнуть туда, где она не нужна.

V>Т.е. ты по ссылке не ходил?
V>А там вполне конкретная задача разбиралась.
Задача по ссылке не относится к тому что ты писал.


V>>>Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.
G>>Завершаться может когда угодно, а коллбеки в JS вызываются строго последовательно. Если же ты попробуешь иницииоровать две асинхронные операции с одним ресурсом в одно время, о получишь или ошибку или одна выполнится после другой. Так что состояние гонки в js ты не получишь никаким образом.

V>Так вот, разбиралась задача чтения из файла в случае асинхронщины.
V>У коллеги получалось так, что колбэки от асинхронных операций приходили не в той последовательности, в какой инициировались.
V>И это нормально для того же overlapped io в виндах, когда мы инициируем более одной асинхронной операции над хендлом, обслуживаемым через IOCP на пуле потоков.
Проблема не в порядке прихода коллбеков, а в том, что чтение и запись файла — неатомарные операции.

Гораздо интереснее ситуация если ты читаешь и пишешь память в коллбеках. Когда у тебя несколько потоков, то можно получить гонку на простом инкременте, в случае одного потока, как в NodeJS — нельзя.



V>Так вот, к счастью (или нет, ХЗ), но node.js умеет обслуживать один хендл только из одного потока.
V>Поэтому моя доработка кода коллеги свелась к тому, чтобы разные асинхронные операции использовали общий хендл файла, а не каждый свой при shared-режиме открытия файла.
V>Вот тебе вполне конкретная задача, где знания о потоковой модели оказались важны.
От потоковой модели оно вообще не зависит. Используя один хендл ты сделал чтение и запись файлов атомарными операциями.


V>>>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
G>>Нет. Никакой ввод-вывод в других потоках не исполняется.
V>Боже, какое нубство. )))
Точно. Ты многопоточность от атомарности не отличаешь


G>>Есть один поток выполнения
V>Есть поток выполнения колбэков одного JS-скрипта.
Это один поток, в котором выполняется весь код, другого нет.


V>Из потоков io в очередь потока JS-интерпретатора вставляются колбэки.
V>Посмотри исходник, там не сложно — каждая структура, привязанная к хендлу, содержит ссылку на т.н. "контекст исполнения".
V>Вот в очередь к этому контексту исполнения и копируются колбэки из других потоков.
Каких "других потоков" ? Node нет "других потоков".

V>>>Причем, я твоё непонимание показываю в каждом сообщении, а ты всё обещал показать моё — но так и не смог.
G>>Чувак, ты о чем? Ты даже про модульность в JS не в курсе. Это проблема решенная 5 лет назад. Ты продолжаешь доказывать, что модульности нет. О чем с тобой еще говорить?

V>В JS модульности нет и не спорь, бо это дилетанство как оно есть.
Я requirejs использовал в 2009 году, вполне себе модули. В node всегда были commonjs модули.

V>Потому что я хорошо знаю, как эмулируется модульность в библиотеках JS — этот трюк прост, как и способы его обхода (даже случайного).
Что ты имеешь ввиду?

V>Т.е. из-за ошибки программиста в стороннем модуле вся эта "модульность" может улететь к чертям собачьим.
Приведи пример чтоли. Вот ты сослался на модуль fs, покажи как "модульность" улетит куда-нить.

V>В JS есть некие соглашения о том, как совместными усилиями разработчиков "модулей" не гадить друг другу в пространство имён.
V>Но "соглашения" — не есть модульность.
Вот тебе код модуля (на TS), поломай в нем модульность: ссылка




G>>Если ты хочешь мою личность обсудить, то ты не туда пришел.
V>Вместо аргументов ты начал раскидываться обвинениями в ошибках, не умея даже эти ошибки показать.
Да я тебя уже носом тыкнул в десяток ошибок, а ты продолжаешь повторять одни и те же мантры, не понимая даже о чем я тебе пишу.


G>>>>И большинству это не помогает. Люди находят workaround и пользуются им всю жизнь, так и продолжая не понимать суть.
V>>>Ну это про маньяков каких нить. ))
G>>Это про подавляющее большинство программистов.
V>По себе других не судят.
Я сужу по тому, что пишут на форумах.


V>>>Половина спрашивающих на форуме С++ — это студенты или вчерашние студенты.
G>>Это как раз показывает средний уровень.
V>Средний уровень спрашивающих?
Сегодня он спрашивает, а завтра отвечает на подобные вопросы.


V>>>Если для node.js на C++ не напишешь АПИ на некую нейтивную функциональность, то вот уже и нет решения на JS.
G>>Нейтивная функциональность в области, где работает nodejs нужна чуть реже, чем никогда.

V>Я тебя расстрою — почти вся функциональность node.js нейтивная.
V>Я имею ввиду основные его JS-либы.
V>Это всё обертки.
И что? Они уже есть, их писать не надо, бери и используй. Для этого не надо знать C++.


G>>Да и прокидывание нейтивной функциональности в NodeJS сложной задачей не является от слова совсем.
V>Тем не менее, для прокидывания такой функциональности надо быть нейтивным спецом явно посерьезнее, чем спрашивающий на форуме по ссылке.
V>Получается, ты сам себе противоречишь. ))
Я тебе говорю, что на Node можно решать сложные задачи и не зная C++.
А также говорю, что уровень C++ программистов не обязательно достаточный чтобы решать на нем C++ задачи, которые легко решаются на Node.
Где ты увидел противоречие?


V>>>JS как язык внутри пуст как абстрактное зеро.
G>>Что значит "внутри пуст"? Какой яызк внутри непуст?
V>С++, C#.
V>Оба умеют работать с АПИ ОС, т.е. оба могут реализовать любую востребованную функциональность.
Путем написания оберток над АПИ ОС, как и в JS. Ты сам себе противоречишь


V>>>Вся его полезная функциональность поставляется нейтивным хостом или нейтивными же "обертками"-библиотеками над имеющимся плюсовым кодом.
G>>У лобого яызка так. С++ тоже внутри пуст, не дёргая API ОС он вообще ничего сделать не может.

V>Может и делает. Например, в драйверах обращается к специальным участкам отображенной на DMA памяти, пишет в порты ввода-вывода.
Драйверы на C++ ? Где такую траву берешь?



V>>>Поэтому, на JS сейчас пишут медленно и отлаживаются долго.
G>> На JS пишут и отлаживают быстрее, чем на C++
V>Это уже сильно устаревшая информация.
Доказательство?
Может покажешь Excel в 30 строк на C++, предположив, что есть DOM API для C++?


V>>>И чем больше по размерам проект, тем меньше продуктивность.
G>>Везде так, как бы тебе не казалось обратное.
V>На проектах С++ и C# это ровно наоборот. Чем больше накапливается хелперов, чем более высокоуровневой получается "платформа" конкретного приложения, тем выразительней получаетсяя целевой код и тем проще его поддерживать.

Палишься, у тебя не было крупных и сложных проектов.

V>Сам сижу на большом нейтивном проекте уже несколько лет и вижу, что его с каждым годом всё проще развивать, по мере накопления собственных библиотек.
Это вовсе не от накопления хелперов, а от того, что со временем скорость появления новых задач падает.

V>Потому что, повторюсь, в строго-типизированной среде не происходит "засорения" пространства имён, не происходит засорения перегруженных сигнатур ф-ий и т.д. А в JS можно убить любую ф-ию через создание одноимённой переменной. Или просто переопределить уже имеющуюся и знать никто не будет. ))
Я тебе уже привел пример с модулем, "убей" функцию internal путем создания переменной вне модуля.
Как получится — возвращайся.



V>И я не утверждаю, что нет ср-в борьбы с этим — вот, эмуляция модульности, к примеру.
V>Но я вижу, как легко программисты ломают все эти сугубо вербальные гарантии.
V>Не специально ломают, ес-но, в этом и проблема.
Ты настолько не в теме, как писать на js, что дальше нет смысла общаться.
Как сломаешь модуль добавлением переменной вне модуля — приходи.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

_>>>Теперь язык работающий на подсчёте ссылок называется managed? ) Как интересно то... )))
G>>Это во многом философский вопрос.
G>>Как по мне managed-язык это тот в котором временем жизни объектов управляет "среда". Это может быть отдельный "рантайм" в виде GC, а могут быть и правила компилятора, которые в нужные места втыкают вызовы. Самое главное что это происходит неявно для программиста, снимая с программиста заботу об этом.

_>Правильно ли я понимаю, что если я напишу на C++ программу, в которой не будет ни одного явного new/delete, то это будет означать, что программа написана на управляемом языке? )
Нет. Ты явно будешь использовать умные указатели или аналогичные классы, управляющие ресурсами. Если ты вдруг не используешь эти классы, то получится утечка.

Еще раз managed это когда "среда" дает тебе гарантии, а не программист что-то делает, чтобы утечек не было.

Здравствуйте, Serginio1, Вы писали:

S> Кстати интересная статья История о том, как мы перевели проект в почти четверть миллиона строк на TypeScript и остались в живых

Четверть миллиона строк, Карл!

Решение использовать TypeScript в нашем проекте оказалось правильным, принесло много хорошего. В частности, это — повышение производительности труда, улучшение управляемости кода, поддержка ES6.

Процессно-ориентированное программирование.

Здравствуйте, vdimas, Вы писали:

G>>Swift вполне себе managed и подсчет ссылок от программиста полностью скрыт
V>Ну вот я тестирую показанную "библиотеку":
V>От программиста всё "скрыто". ))
Ты упоролся? Как скрыто, если это новые типы? И где гарантии? Кто запретить тебе забить на эти типы? Как ты будешь интегрировать свои типы с типами, которые такой же упоротый напишет в другом модуле?


G>>В этом случае если создатели решат вместо подсчета ссылок сделать GC или прикрутят мощный escape-анализ для размещения объектов на стеке, то с точки зрения кода ничего не изменится.
V>В моём случае аналогично — подменю тонкости объекта Box и с точки зрения зависимого кода ничего не изменится.
Только в том случае если программист явно использует созданные тобой типы.
В этом собственно и разница.


G>>Обратный пример — если .NET Native переведут на подсчет ссылок, то C# не станет unmanaged языком.

V>Не переведут.
V>Без идиомы совместной работы "слабых" и "сильных" ссылок рефкаунтинг не живёт.
V>В Swift эта идиома есть изкаробки, ес-но и обязательна к применению через ключевое слово weak.

В .NET есть WeakReference если что, только к разговору это не относится.

Здравствуйте, gandjustas, Вы писали:

G>>>Обратный пример — если .NET Native переведут на подсчет ссылок, то C# не станет unmanaged языком.
V>>Не переведут.
V>>Без идиомы совместной работы "слабых" и "сильных" ссылок рефкаунтинг не живёт.
V>>В Swift эта идиома есть изкаробки, ес-но и обязательна к применению через ключевое слово weak.
G>В .NET есть WeakReference если что, только к разговору это не относится.

Здравствуйте, gandjustas, Вы писали:

G>Еще раз managed это когда "среда" дает тебе гарантии, а не программист что-то делает, чтобы утечек не было.

Swift никаких гарантий не даёт. Получить в нём утечку памяти — как два пальца об асфальт.

Здравствуйте, Lloyd, Вы писали:

V>>Это багфиксы в основном.
V>>Плюс поддержка новых фич языка.
V>>Мы же говорили о движке исполнения, верно? А ему на фичи языка немного покласть, он байт-код исполняет.
L>Какой байткод в js???

Ну назови p-code, какая разница?
Суть в том, что это разные уровни абстракций.
Из разного синтаксического сахара можно получать один и тот же p-code.
Это позволяет независимо развивать синтаксис языка и среду исполнения.


L>Откройте их блог, они до сих пор перформанс улучшают, причем не на доли процентов, а существенно.

Ты лучше бы сравнительные тесты посмотрел.
Если в 2011-м году v8 был быстрее Мозиллы и IE, то сегодня в лидерах Edge, потом Лиса и только потом Хром.