Здравствуйте, Somescout, Вы писали:
I>>Твой вариант сливает в любом случае, у него единственная возможность запуститься, когда юзер купил офис и пермишны позволяют запустить Эксель. Это смешное количество юзкейсов. На всех остальных у него ни единого шанса. А вот вариант в 30 строчек кода работает уже давненько.
S>И где это условие в исходном сообщении? Вас обидело, что вам тычут в лицо кодом с теми же проблемами, что и у вашего кода. И вы судорожно пытаетесь приплести "платно"/"бесплатно"/"кроссплатформенно", лишь бы не признать что исходный пример не более чем забавный однострочник, не демонстрирующий никаких преимуществ языка, и за использование которого в более-менее серьёзном проекте должны бить канделябрами. Насмерть.
В решении про 30 строчек все хорошо — работает во всех браузерах всех актуальных платформ искаропки и ничего дополнительно покупать не нужно.
Твое решение работает только в сильно частном случае.
Ты, кстати говоря, сам же подменил условие задачи — нигде не было требования иметь на компе пользователя установленый Офис. А ты его ввел своим кодом.
Здравствуйте, Ikemefula, Вы писали:
S>>И где это условие в исходном сообщении? Вас обидело, что вам тычут в лицо кодом с теми же проблемами, что и у вашего кода. И вы судорожно пытаетесь приплести "платно"/"бесплатно"/"кроссплатформенно", лишь бы не признать что исходный пример не более чем забавный однострочник, не демонстрирующий никаких преимуществ языка, и за использование которого в более-менее серьёзном проекте должны бить канделябрами. Насмерть.
I>В решении про 30 строчек все хорошо — работает во всех браузерах всех актуальных платформ искаропки и ничего дополнительно покупать не нужно. I>Твое решение работает только в сильно частном случае.
Это ваш способ спора — повторять один и тот же тезис до посинения? Тогда считайте выделенное моим новым ответом на каждое подобное сообщение.
Здравствуйте, vdimas, Вы писали:
V>Там, где мне на шарповом проекте приходилось писать кучу утилит, хелперов и т.д., там на плюсах объем этих хелперов, во-первых, на порядки меньше (исходный код не в пример более повторно применим), во-вторых, сами эти хелперы пишутся быстрее и шире применимы.
Я бы хотел дополнительно отметить, что благодаря удачной компоновке как языка так и развитости оптимизаций — стоимость абстракций реально или нулевая или около того. А это, имхо, одно из необходимых условий для легкочитаемого и производительного кода.
С другой стороны то, что заложили в дотнет почти с самого начала, затем генерики — даже при туповатом джите показывает хорошие (удовлетворительные) результаты.
Опять же — C++ сам как язык долго стоял, дикая энерционность в поддержке стандартов от производителей компиляторов (про gcc наверное лучше промолчать — ведь его только что-бы скомпилировать — нужна правильная трава, а если кросс-компиляция и не дайбог ещё и какой-нибудь musl — то ещё и правильные патчи). Сейчас то ли стандартов стало больше (и новый на носу) но кажется сииуация всё куда лучше.
Но C++ безжалостен в плане набора. Печатать нужно много. Хотя мне вот лично, в некоторых случаях куда больше нравится когда хедер отдельно — можно сосредоточится на контракте класса. Когда код вперемешку — охвата не хватает. Object browser/class view/document outline и т.п. имхо не сильно решают: детали лезут слишком активно или фичу не умеет ide (document outline студией почему-то не поддерживается, хотя в 2017 ещё не смотрел это). Да и вообще — взяли и почитали файл. А тут ide. Х.з. Понятно что в шарпе определил интерфейс и порядок, но — есть тысяча случаев когда интерфейс/контракт есть, но доп. публичных базовых классов или интерфейсов не хочется (не нужны). Короче — C# неповоротлив. C++ как раз очень подвижен и приспосабливаемый. Но ужа с ежом так никто и не скрестил — или няшность или хардкор.
Брюзжание:
Но, млин, банальное отсутствие тайп алиасов (прозрачные и не прозрачные) на уровне метаданных это жестковато, я уже не говорю о том, что ввести нормально свой тип на основе примитивных — нельзя. Ну энамы не в счёт. Да и вообще — более 10 лет застоя в JIT это жестко. Хотя дело начало двигаться.
Здравствуйте, Somescout, Вы писали:
S>>>И где это условие в исходном сообщении? Вас обидело, что вам тычут в лицо кодом с теми же проблемами, что и у вашего кода. И вы судорожно пытаетесь приплести "платно"/"бесплатно"/"кроссплатформенно", лишь бы не признать что исходный пример не более чем забавный однострочник, не демонстрирующий никаких преимуществ языка, и за использование которого в более-менее серьёзном проекте должны бить канделябрами. Насмерть.
I>>В решении про 30 строчек все хорошо — работает во всех браузерах всех актуальных платформ искаропки и ничего дополнительно покупать не нужно. I>>Твое решение работает только в сильно частном случае.
S>Это ваш способ спора — повторять один и тот же тезис до посинения? Тогда считайте выделенное моим новым ответом на каждое подобное сообщение.
Я уже сказал — можно сравнить оба решения, табличкой, шоб интереснее было. А то может оказаться так, что твоё решение в общем случае то и не работает. Бгг.
Здравствуйте, Ikemefula, Вы писали:
S>>Это ваш способ спора — повторять один и тот же тезис до посинения? Тогда считайте выделенное моим новым ответом на каждое подобное сообщение.
I>Я уже сказал — можно сравнить оба решения, табличкой, шоб интереснее было. А то может оказаться так, что твоё решение в общем случае то и не работает. Бгг.
Всё таки у всех подгорело жестко по поводу 30-100 строк. Хватит ерундой страдать. Посчитайте число строк в google sheets и других вебовых аналогах (я офисом вебовым не пользубсь, десктопный душе ближе, а вот вебовый — гугловый юзаю).
Здравствуйте, fddima, Вы писали:
F>Всё таки у всех подгорело жестко по поводу 30-100 строк. Хватит ерундой страдать. Посчитайте число строк в google sheets и других вебовых аналогах (я офисом вебовым не пользубсь, десктопный душе ближе, а вот вебовый — гугловый юзаю).
Не мешайте мне страдать ерундой в свободное время (да и в несвободное, тоже не мешайте )
Здравствуйте, gandjustas, Вы писали:
G>Кстати почему подобного не наблюдается в форуме .NET? Там на любой простой вопрос тебе прилетит исчерпывающий ответ.
А там много вопросов именно по языку, а не по фреймворку?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, fddima, Вы писали:
F> Но C++ безжалостен в плане набора. Печатать нужно много. Хотя мне вот лично, в некоторых случаях куда больше нравится когда хедер отдельно — можно сосредоточится на контракте класса. Когда код вперемешку — охвата не хватает. Object browser/class view/document outline и т.п. имхо не сильно решают: детали лезут слишком активно или фичу не умеет ide (document outline студией почему-то не поддерживается, хотя в 2017 ещё не смотрел это). Да и вообще — взяли и почитали файл. А тут ide. Х.з. Понятно что в шарпе определил интерфейс и порядок, но — есть тысяча случаев когда интерфейс/контракт есть, но доп. публичных базовых классов или интерфейсов не хочется (не нужны). Короче — C# неповоротлив. C++ как раз очень подвижен и приспосабливаемый. Но ужа с ежом так никто и не скрестил — или няшность или хардкор.
Есть .Net Native. Как раз симпатичный такой ЁжеУж.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Есть .Net Native. Как раз симпатичный такой ЁжеУж.
Давай по шагам какие пакеты поставить что-бы хотя бы портабельный код получился в целевой экзешник. Заодно не забудь про тонну нативных .obj которые там тоже должны оказаться. Я или что-то пропустил, или это всё пока в воздухе.
Здравствуйте, gandjustas, Вы писали:
V>>Поэтому, твои "только формочки" смешны. Ты не в теме. G>Если ты в теме, приведи примеры, а не теории.
Я привел — CreateObject(Type, Host)
Поведение зависит от реализации серверного компонента — может быть создан новый экземпляр, а можно получить имеющийся через COM+.
V>>Это я заметил еще в 2008-м году, когда ты эпично засветился незнанием спецификаций CLI. G>Прости, но ты в каждой второй теме чушь говоришь.
Не прощу. Ты там тоже много строил важного из себя, пока дело не дошло до дела.
Сразу же и посыпался.
В общем, ничего не изменилось.
Если ты чего-то не понимаешь, что это лишь парадокс бла-бла, а не "чушь".
V>>Говори уже прямо — знания вредят. G>Исключительно теоретические знания вредят. G>Например твои знания про ректоры и протракторы не помогают тебе в понимании работы nodejs от слова совсем.
А я тут причем? Мне хватило 15 мин, чтобы выяснить модель работы node.js и объяснить коллеге его собственный код.
А так же показать, как следует обходить грабли, на которые он наступил.
Да я вообще такого подхода не понимаю, сорри, работать с платформой и не понимать, что там происходит.
Потому что это понимание требовалось даже на дебелом VB — я там тоже за коллег порядочно разгребал.
V>>Если речь шла о заказухе, то на С++ всю жисть писали лишь критичные к эффективности библиотеки-компоненты или простое клиентское GUI, вместо VB — когда нужно было хостить OLE-документы в приложухе. G>В данном случае речь про крупняк, типа банков, где наколеночные решения на VB считались моветоном, а аналогичные на java — норм, только пафоса больше. И денег на разработку достаточно. Я например видел такое в РЖД.
Да какая Джава в середине 90-х, о чем ты?
Она более-менее стала активна в конце 99-го года, после выпуска стандарта 2.
Твои уникальные примеры использования джавы для чего-то серьезного с 96-го года — это те самые исключения из правил.
V>>Практически нет. V>>Я, вроде бы, довольно четко описал, какие технологии потеснила Джава. G>Ты написал про DCOM и CORBA, они вроде как не C++. Тогда на чем были написаны эти серверы? Все на VB?
Конечно, на VB. Потому что лезли по DAO, а после 97-го года по ADO в базу.
Причем, тогда запросто работали поверх файловых баз данных, бо это было слишком тормозно — работать через приложение-прокси с базой-сервером.
Хосподя, получается, что ты вообще был не в курсе, откуда вообще растут ноги у сетевых серваков приложений.
От необходимости совместного использования файловых баз и растут.
Потому что обращение к расшаренным файлам базы данных по сети зачастую делало эти файлы битыми из-за сбоев.
V>>Именно что. Джава потеснила Дельфи, VB и кучу других таких же приблуд. G>У нас в крупняке было такое же засилие C++ (DCOM и прочее), которое потеснила Java. А формоклепство для малого и среднего бизнеса на VB\Делфи жаба потеснить так и не смогла, ни тут, ни там. .NET смог, но это уже было в 2005.
Мы не про формоклёпство.
На GUI джава не взлетела сразу же.
V>>До потеснения С++ у джавы ручки коротки — мне сложно представить С++ программиста, который полностью перелезет на Джаву или Шарп. G>Даже на этом форуме сотни таких.
А копнёшь такого немного, так выясняется, что плюсовый опыт мизерный, больше дельфового.
V>>Но системная Exchange Management Console — всё еще нейтивная. G> Она с 2013 года в вебе
Вот. С 2013-го , ы-ы-ы.
G>До 2013 версии в Exchnage действительно было много нейтива.
Так а я после и не смотрел, потому что Exchange, де-факто, стал терять популярность из-за развития облачного направления как такового.
Всё, финита ля комедия.
Организации больше не хотят разворачивать и поддерживать сложную серверно-сетевую инфраструктуру у себя, его продажи неуклонно падают.
V>>Так же как утилиты командной строки. G>С 2013 года на PowerShell.
Опять 2013.
Блин, сплошное ЧТД.
Нормально так дотнет "откусил" нишу у C++ аж через 10 лет, причем, сугубо в тех продуктах, которые были поставлены на финальный путь, такскаать. )) Ну чтобы сделать возню с ними максимально дешевыми.
По факту, все эти эксченжи уже не приносят MS ощутимых денег, как вct 90-е и первую половину 2000-х.
Эта тема, считай, успешно сдохла.
V>>Как и сами сервайсы виндов, запускаемые в основных ролях Exchange — там дотнетом и не пахло никогда. G>Кроме поиска все managed G>Лучше пойди изучи вопрос.
Лучше ты пойди посмотри на запускаемые бинарники сервисов.
V>>Все эти технологии репликации, в том числе асинхронной, все кластерные вещи — всё это нейтивное. G>Уже managed. V>>В 2010-м году Exchange перешел на технологию DAG, которая, внезапно, тоже всё еще нейтивная. G>Уже нет
И там и там с 2013-го года? ))
V>>Любые игровые фреймворки, даже Unity, который некоторые нубы всерьёз считают дотнетным, ы-ы-ы. G>И че? Все равно здравый человек будет писать на том, что дает максимальную продуктивность. И это будет не C.
Конечно не С.
Современный С++.
С замыканиями, наконец-то непосредственными сколь-угодно сложными вычислениями времени компиляции (const expr) и кучей удобных в 2017-м году библиотек на любой вкус и цвет по ЛЮБЫМ направлениям. Ну т.е., действительно по любым. Даже по тем направлениям, которые Джаве, Дотнету и уж тем более JS никогда и не снились.
Это практика.
ngix развился из наколенного поделия в один из самых востребованных серваков.
Ни один дотнетный продукт такого пути не прошел.
Факт.
V>>Для разработчика — ровно наоборот. G>Суммарные затраты на разработку в заказухе больше, чем в продуктах. Программист потенциально может заработать больше. Дальше уже спрос, предложение и умение продать себя.
Да не платят нифига.
В заказухе своя атсмосфера.
Там проще набрать толпу "обезъянок".
Что я и наблюдал неоднократно.
"Продать" себя можно лишь в роли Каа над Бандерлогами.
Ну это весьма специфический род деятельности, знаешь ли.
V>>Набирают обычно всякий неопытный сброд, текучка в таких конторах сумасшедшая. G>Это от конторы зависит. Я в продуктовых видел текучку и видел в заказухе команды, которые существуют много лет.
И я красножопых обезъян с синей жопой видел, и?
Де-факто у этой породы жопа красная по-определению.
G>>>Именно для заказной разработки имеет смысл повышать продуктивность, а не для продуктовой. V>>Продуктивность на жабе, шарпе и особенно на JS сегодня уже никого не впечатляет, а местами сильно отстаёт. G>По сравнению с чем?
По сравнению с альтернативами.
V>>Согласно замерам Гугла, стоимость поддержки решений на JS растёт экспоненциально с размером кодовой базы. G>Странно было бы если бы гугл утверждал обратное.
Я правильно тебя понимаю, что ты обвиняешь крупнейшую на сегодня сетевую контору, которая ведет разработку самой популярной ОС для смартфонов, которая финансирует на 100% разработку самых популярных современных браузеров — Хрома и Лисы, которая дала тебе твой node.js, jQuery и т.д., что она "глупая"? Что они перевели ключевые проекты, приносящие им максимальное бабло, а именно: adWords и adSense на Dart сугубо из прихоти?
С такими закидонами можно было даже не начинать спор, ИМХО.
Это уже за гранью добра и зла.
V>>Для С++ — ровно наоборот. G>Да не заливай. Такого бреда я давно не видел.
Ты много чего давно не видел.
Например, я многие годы использовал шарп для прототипирования по своей работе.
Т.е. вот на шарпе прототип, отлаживаю, шлифую его АПИ и сценарии, а потом перевожу на С++.
Последний раз я сделал это пару лет назад и понял, что это был действительно последний раз и вообще это было уже глупо.
Аж осадочек остался.
Потому что шарп уже не дал НИ-ЧЕ-ГО.
Собсно, единственная причина, по которой еще имело смысл прототипировать на шарпе — это не сам шарп, а решарпер в Студии.
Думаю, ты хорош понимаешь, почему так.
Наколенный изначально вариант в случае решарпера можно относительно дешево доводить до боевого варианта промышленного качества.
Но как только у меня появился более-менее работащий решарпер для плюсов — то это сразу приговор таким "макетам".
Да меня вообще бесит, как много кода сегодня надо на шарпе для простейших вещей в сравнении с плюсами. ))
Поверь, когда делаешь подобную глупую работу, трудно отделаться от раздражения.
V>>Чем больше накапливается библиотек, тем дешевле поддержка целевых продуктов. G>А при чем тут размер кодовой базы?
При том, что у некоторых языков проблемы сопровождения кода на них зависят от размера кодовой базы.
А чего ты хотел от языка, который предназначался для небольших скриптов на странице?
V>>В этом суть статически-типизированных языков. G>Это ты чушь какуюто сказал.
Опять парадокс бла-бла?
V>>И в этом смысле JS был, есть и будет гирей на ногах. G>Тот JS, про которы ты говоришь (образца 93 года) — да. Современный — нет.
Самообман.
Никакой async/await не спасёт, если можно забыть (тупо забыть) про аннотации типов.
И это, заметь, я еще не придираюсь к тому, что ты, говоря про JS, имеешь ввиду TS (судя по твоим комментам в соседних ветках).
V>>Угу, особенно 1C. )) G>1С это платформа, а сама программа (конфигурация) пишется а vb-подобном языке.
Это очень активно разрабатываемая платформа и неимоверно широко используемая платформа.
А вот дотнетный Парус еле пыхает.
Другая модель.
Парус — это "сложные" заказные модули на "простой" платформе, а 1С — строго наоборот — простые заказные модули на очень сложной платформе.
У меня друг в 1С работает, т.е. разрабатывает саму 1С.
И да. Из vb-подобного языка вызываются очень мощные прикладные нейтивные сценарии — весь ORM, транзакционность, версионность данных (исторические данные, вернее, "исторические поля" — уникальная и очень мощная фишка 1С), архивация, умная репликация, кеширование и т.д. до бесконечности. Ничего себе "платформа". Это ~50% кода в современном шарповом приложении.
Да чего там говорить. В современном шарповом приложении всё обычно сделано банально ХУЖЕ.
С худшим качеством, с меньшим количеством прикладных сценариев, с меньшей надёжностью и т.д. и т.п.
Да чего там говорить вопрос деревянного представления/отображения данных БД-ГУИ до сих пор один из самых обсуждаемых.
И это 2017-й год.
V>>Любые корпоративные системы, где функциональность как в 1С можно допиливать неким кодом/скриптом — они нейтивные. G>Ага, Axapta или navision, которые как раз mamanged. Не выдавай желаемое за действительное.
Учите матчать, хосподя.
Компилятор X++ стал иметь ОПЦИЮ генерации в дотнетный байткод только в 2010-м году.
При этом, на такой код накладывается куча ограничений: https://msdn.microsoft.com/en-us/library/hh397320.aspx
G>>>Софт для телефонов пишется на Java, iOS, .NET\Xamarin. Из них нативный только iOS с натяжкой. V>>iOS без натяжки хардкорно нейтивный. G>Я чето неточно написал. На iOS два языка, нативный Objective-C и вполне себе managed swift.
Да ты постоянно что-то неточно тут пишешь.
Как и базовая NS-либа iOS, язык Swift использует тот самый харкорный нейтивный reference-counting.
Ни в одном из мест Swift не managed.
Он такой же нейтивный как код VB при компиляции с галочкой "оптимизация", где reference-counting разруливался компилятором VB весьма разумно (исключались избыточные операции инкремента-декремента), и сами вычисления тоже нехило так оптимизировались в нейтив с недоступной для любого даже современного JIT эффективностью конечного кода.
Люди, которые говорили про "тормозной VB" часто не понимали о чем речь.
Они так говорили часто на VBA, или на те приложения VB, где общались объекты из разных аппартаментов через сериализацию-маршаллинг, например, при обращению к OLE-серверу, живущему в другом процессе. ))
V>>Так вот, возвращаясь к нашим баранам — никакая AOT-компиляция не спасёт JS, потому что для KS она невозможна. G>Это ты вообще к чему сказал? JS и без AOT нормально работает (всех устраивает).
JS работает хуже чем VB когда-то.
Вся его польза — это в переиспользовании тонны уже написанных сниппетов кода, которые изначально были рождены для клиентских сценариев, кста.
G>NaCL, Dart уже сдохли, первый похоронили официально, второй пытаются насильно поднять из могилы. G>WebAssembly — взлетит, будет прекрасно. Но пока новости не обнадеживающие.
И опять ошибка. NaCL — это и есть будущее WebAssembly, когда пройдут промежуточную фазу webasm.js.
Собсно, если у тебя не запрещены автоматические обновления Хрома или Лисы, то NaCL уже в твоём браузере больше недели.
А про Dart вообще глупо, это спор ни о чем. Если Гугл переводит свои ключевые продукты, приносящие ему те самые миллиарды, на Дарт, то у последнего не останется других возможностей, кроме как "взлететь", как "взлетела" jquery с подачи Гугла. Там даже если что-то пойдёт не так, Гугл выпишет "волшебного пенделя" и всё пойдёт так, не волнуйся. Когда речь о таких деньгах, то о вкусах не спорят — нужны конкретные кач-ва языка/платформы. JS эти качества обеспечить НЕ СМОГ, поэтому обсуждать тут нечего.
Помнится, про Swift тоже некоторое время нехорошо шутили, а теперь на ObjectC пишут только совсем упоротые. Вся разработка под iOS переехала на Swift и теперь только рада, что сдыхалась от уродца.
Здравствуйте, gandjustas, Вы писали:
V>>TS был доработан до "понимания" AtScript. G>Ты подробнее вопрос изучи для начала. G>В AtScript были аннотации. В ES не было аннотаций, предложение было на ранней стадии. В TS согласились добавить аннотации в формате AtScript пораньше, чтобы разработка Angular2 велась на TS. Когда в стандарте ES проработали аннотации, то в TS и Angular2 стали использоваться аннотации ES.
Пффф...
Мало маслянное.
Аннотация там одного и того же формата — через ':'.
Более того, основу W3C составляют представители MS, Гугла и Мозиллы, где последние де-факто являются подразделением Гугла с 2011-го года.
Поэтому, эти ребята де-факто порешали м/у собой как и что.
И порешали они так, что TS стал понимать код AtScript.
Тебе это было сказано с самого начала, но ты упираешься.
G>>>Dart появился потом. V>>TS был представлен в 2012-м, а Dart — в 2010-м. G>Я говорю что Angular2 dart появился позже перехода на TS.
Забегал...
Ну побегай.
Хотя, чего это я?...
Вообще, я рад, что ты открыл интернет и хоть что-то почитал по своему основному направлению деятельности.
Не зря я время потратил. ))
Не благодари.
О! Про самое главное-то я и забыл! ))
Конечно нет, иначе как же тогда компиллироваться в JS?
S> Опять же TS это прежде всего интеллсенсе и статическая проверка. Ты же все напираешь на статическую типизацию для компиляции.
Да.
Потому что работы по Dart начались одновременно с тем как Гугл стал рассуждать о пределах оптимизируемости в v8 — в конце 2010-го.
S>А для этого нужен свой Фреймворк в браузере.
Свой байткод.
Если ты недавно обновлял браузеры Хром или Мозиллу, то он уже у тебя на машине.
S>А для этого и .Net Core прекрасно подойдет. MS вполне мог бы такой браузер сделать.
Верно. В этом месте я ругаю Гугл, что они дали миру еще один стандарт, вместо доработки до нужд веба одного из имеющихся.
Хотя, если начистоту, изобретённый с 0-ля байткод максимально близок к машинному, к тому же оптимизирован.
Байткод дотнета или джавы принципиально НЕ может быть оптимизированным.
Наверно, дело именно в этом.
С другой стороны, байткод дотнета может описывать операции над плоской памятью.
В общем, ХЗ. Кто-то из них явно проявил баранью упертость. А может обе стороны.
S>На данный момент у Dart нет никаких премиуществ перед TS.
Это пока основной кейз использования Дарта — трансляция с исходника в исходник, т.е. в JS.
Но этот кейз вот уже несколько дней как перестал быть основным, бо уже у тебя в браузере.
Посмотрим, это дело времени.
S>Кстати я бывший дельфист, но больше программирую на C#. Для меня TS дается легко, а если будет транслятор из C# в TS (а может он и есть), то многие вещи не сложно перетащить
В Dart перетащить из C# намного проще — языки ОЧЕНЬ похожи.
Я не удивлюсь, если когда-нить они станут близнецами. ))
Я отвечаю сразу всем, это просто наиболее удачная подветка:
1. Эта жжж(tm) неспроста что вебасмом занялся именно V8 — при необходимости сервичы браузера он протащит как родные.
2. Понятно, что готовый JIT.
3. Он постоянно фиксится и развивается. Может новых супероптимизаций он и не делает внутри, но отсыл к русской вики конечно "нагляден". Я трэкаю иссу с вебасмом связанные с V8 очень давно. Настолтко что уже давно заколебался читать. Но он (V8) по прежнему способен скушать несколько мегабайт JS меньше чем за секунду и не подавиться.
4. Oilpan, GC и кучи объектов. Этот момент я опустил. Вроде течь память щас не должна. вебасмовы инсинуации некоторых я бы реально отложил: браузеры идут по пути объединения DOM и JS куч. Если в webasm гейт будет на подсчете ссылок — это хана. Анлуляр 1 — тёк очень жестко без разрешения проблемы более нескольких лет, казалось бы в "родном" гугловом браузере (что интересно проблема в FF и IE — на тот момент решена). И инснуации про DOM "API" без GC — это бредятина. Таких в принципе нет, т.к. W3C DOM не декларирует это никак но неявно предполагает. Любой кто сделает своё убожище на эту тему — должен караться. W3C DOM API покрывает всё в XML документах. Бери JS, бери Python, бери C# и System.Xml = всё это очень близко. Более того на тот же дотнет весь W3C апи ложится один в один (даже больше чем System.Xml). Высеры навроде System.Xml.Linq — это жестокий компромис: удобный API но абсолютная не интеропность между языками/людьми. Люди банально путают Descendants() и Elements(), а это важно бывает не ток по перфомансу но и по поведению.
Короче — я рад что они зарелизились. Это круто т.к. давно ж готово было. Детали чёрточы держали. Буду рад когда они прокинут сервисы браузера вместе с DOM и сделают SDK под C++.
Это не такой ужас. Я прям сейчас занят почти тем же — протаскиванием микровызовов с доступоп к DOM во внешний процесс. У Serginio1 — всё наоборот. Просто наше отличие — я реализую максимально эффективно интерфейсы заказчика, и говорю ему прямо, что это некамильфо. А Serginio1 нарисовал рантайм биндинг который считал нужным.
Вместе с тем — не надо обольщаться: в тру C++ коде хрома столько раз происходит ахинея, и проглатывание ошибок, что мы со всем своим опытом — деточки на этом поприще.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, gandjustas, Вы писали:
G>>Кстати почему подобного не наблюдается в форуме .NET? Там на любой простой вопрос тебе прилетит исчерпывающий ответ.
Ops>А там много вопросов именно по языку, а не по фреймворку?
Последнее — то выпад про exceptionless code конечно же. На эту тему хуже чем в хроме — я не видел нигде. Я ещё раз отмечу — не в blink/webkit, хотя там таже телега.
У них это устроено так:
— ах, системный вызов послал нас на? ну и хер с ним!
— ах — в этом случае в этом параметре приезжает нулл? ой ну тогда нах (return).
В купе с факторами — это нисколичко не лучше. Я душрй за корректность, затем за оптимизацию на нулах. Но нет: куча кода просто ничерта не делает если ему подать нул на вход: а это — прямой путь в ад. Собственно они там давно. Но это не про C++ — это больше про гугл и их браузер.
Понятно что в шарпе определил интерфейс и порядок, но — есть тысяча случаев когда интерфейс/контракт есть, но доп. публичных базовых классов или интерфейсов не хочется (не нужны). Короче — C# неповоротлив. C++ как раз очень подвижен и приспосабливаемый. Но ужа с ежом так никто и не скрестил — или няшность или хардкор. 
Она с 2013 года в вебе 
