Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Ну вот ты пользуешься им, насколько я понял, т.е. должен понимать, верно? G>>Это совершенно пофиг, ты можешь пользоваться паттерном и не знать как он называется. Название в данном случае искусственное.
V>Дело не в названии, а в гарантиях.
Каких гарантиях? V>node.js помимо всего прочего, что операции ввода-вывода для каждого отдельного файлового хендла будут привязаны к одному и тому же потоку.
Ты не в курсе что node однопоточный? В смысле вообще однопоточный. Даже коллбеки попадают во внутренний event loop и обрабатываются одним потоком. Это и на сервере и на клиенте.
V>Тут на сайте был разбор примеров, где это имело значение (разбирал я с Ikemefula). Т.е., человек работает с языком, а что там на самом деле происходит — понятия не имеет.
Пока что ты показываешь, что понятия не имеешь про современный JS.
V>С++ бъет по рукам за ошибки, вызванные непониманием происходящего.
И большинству это не помогает. Люди находят workaround и пользуются им всю жизнь, так и продолжая не понимать суть.
Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
V>Я уже всё сказал: V>
V>Я так думаю, что программист с ростом должен уметь решать всё более сложные задачи.
Как это связано с языками? Сложные задачи могут быть на любом языке.
Вполне может оказаться так, что сложная задача на одном языке в другом языке становится примитивной. Поэтому и надо повышать продуктивность и изучать более мощные языки.
V>Можно научиться быстро работать руками на конвейере, а можно сделать робота вместо десятка таких "ловких на руки" человек.
Аналогии интеллектуального труда с конвейером сразу идут в мусорку.
V>Оформившиеся принципы разработки на С++ — именно такие, заключаются в "роботизации" и это даёт дикий профит.
Думаешь C++ тут уникален?
V>Ну и еще в 2002-м году, с выходом первого дотнета, уже тогда всё было сказано — "разгадка" продуктивности джавы и дотнета заключается больше в мощных библиотеках, поставляемых с языком, чем в св-вах языка. Просто св-ва языка позволили участвовать в разработке этих либ "дешевым" разрабтчикам, поэтому и получилось сделать такие либы бесплатными. А как только С++ оброс кучей бесплатных либ (это ж важно, бо платных на него хватало во все времена), так сразу разработка на нём стала куда как более продуктивной, чем на шарпе (кроме сценариев linq-выражений).
Ты сам-то понял что сказал?
Пока языки имеют примерно одинаковые возможности, то разница заключается в основном в библиотеках.
C# первой и второй версии мало отличались от Java и уступали C++ во многом, но .NET помог занять нишу. Потом появился linq и java с С++ начали отсасывать. Если бы не андроид и покупка жабы ораклом, то жаба могла бы сдохнуть.
Потом то же самое произошло с async\await. Сейчас появился C# 7 с огромной кучей новых фишек для продуктивности. Это конечно не революции типа linq и async, но тоже двигает язык вперёд.
V>Собсно, на сегодня это даже не сравнимо, бо в скорости написания кода C# уже резко отстаёт, хотя еще в 2005-м резко обгонял плюсы.
Да конечно Ты наверное и C# последний раз году в 2005 видел. C# до сих пор самый продуктивный серверный язык. Теперь еще и честно кроссплатформенный.
Кстати недавно написал небольшой код на C# и .NET Core, заняло полдня примерно. Чувак решил переписать на C++ и через неделю бросил.
V>Просто посмотри на вот эту библиотеку: http://www.rsdn.org/forum/prj.codejam V>Для современного С++ ничего подобного уже не нужно.
Для .NET года с 2005 не нужно. при появлении достаточной массы кода на C# команда разработчиков начала тупо смотреть какой код люди пишут и повышать продуктивность написания такого кода.
Здравствуйте, gandjustas, Вы писали:
V>>Но показать ты этого не в состоянии, я правильно тебя понимаю? G>Я могу тебя потыкать в каждое твое ошибочное утверждение, но мне лень.
Тебе не лень, ты не можешь.
G>>>В конкретные места тебя тыкнуть? V>>Ну конечно, если ты обвиняешь человека в ошибке, то надо эту ошибку показать или немедленно извиниться. G>Ты, как и многие, утверждал, что модульности нет. А она внезапно есть. Причем дольше чем ты знаком с JS.
Внезапно модульности в JS нет.
Ты этого, очевидно, не понимаешь.
А с JS я знаком еще с тех дней, когда ты в школе учился.
G>Ты утверждал что v8 не развивается, в чем ошибся.
Тебе стоит опровергать мои утверждения относительно того, что именно "развивается" в v8.
Но предметность тебе не даётся, вестимо.
G>Ты даже не удосужился зайти на страницу обсуждаемых проектов.
ЧТД. Очередной насос из пальца.
По делу что-то будет?
Или сольёмся как в случае "Excel на JS"? ))
Здравствуйте, vdimas, Вы писали:
V>Перегрузка операторов — это весьма популярный приём в С++, т.е. фича востребованная, при её наличии.
Можешь показать примеры перегрузки операторов, кроме случаев:
1) Математических объектов, когда перегружаются операторы для сложения\умножения векторов\матриц\итд
2) Перегрузки оператора ->, ()
3) Перегрузки >> и << для потоков
?
Я хочу понять реальные кейсы полезного использования.
Здравствуйте, vdimas, Вы писали:
V>>>Последние серьезные изменения были в 2011-м, они упёрлись в "непреодолимые проблемы" и выступили с инициативой NaCL. L>>Каждые 6 недель (+/-) у v8 выходит новый стабильный релиз.
V>Это багфиксы в основном. V>Плюс поддержка новых фич языка. V>Мы же говорили о движке исполнения, верно? А ему на фичи языка немного покласть, он байт-код исполняет.
Какой байткод в js???
V>До 2011-го активно изменялся именно движок, в него добавлялись новые принципы ускорения — например, типизазия на исскуственно-вводимых структурах, "мемоизация" такой типизации до тех пор пока в ф-ию подают аргумент такого же типа и т.д. Собсно, это был потолок, поэтому они стали тратить усилия на NaCL/WebAssembly.
Откройте их блог, они до сих пор перформанс улучшают, причем не на доли процентов, а существенно.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Но показать ты этого не в состоянии, я правильно тебя понимаю? G>>Я могу тебя потыкать в каждое твое ошибочное утверждение, но мне лень. V>Тебе не лень, ты не можешь.
Я не могу, мне лень
G>>>>В конкретные места тебя тыкнуть? V>>>Ну конечно, если ты обвиняешь человека в ошибке, то надо эту ошибку показать или немедленно извиниться. G>>Ты, как и многие, утверждал, что модульности нет. А она внезапно есть. Причем дольше чем ты знаком с JS.
V>Внезапно модульности в JS нет. V>Ты этого, очевидно, не понимаешь. V>А с JS я знаком еще с тех дней, когда ты в школе учился.
И похоже это последний раз, когда ты JS видел.
G>>Ты утверждал что v8 не развивается, в чем ошибся. V>Тебе стоит опровергать мои утверждения относительно того, что именно "развивается" в v8.
А ты чендлог посмотреть не можешь? Или тебе рассказать про то, как появился async\await в v8?
V>Но предметность тебе не даётся, вестимо.
Я все еще надеюсь, что ты сам пойдешь прочитаешь, но надежда угасает.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gandjustas, Вы писали:
G>>Ты не понял, что этот пример исключительно для демонстрации мощи JS и к реальному приложению не относится? KV>А ты не понял, что тем самым признался, что демонстрируемая мощь JS к реальным приложениям не относится?
Спалился, да. Потроллить хотел народ, чтоб попотели переписывать кусок в 30 строк на других языках. В итоге сделал только один, и то на C#.
Здравствуйте, gandjustas, Вы писали:
G>Еще раз. 99,9% — формочки. Серверный vb может и был где-то, но я его в глаза не видел ни разу.
Я тебе сразу и сказал, что ты не видел.
Ты пришёл в отрасль уже относительно поздно, чтобы что-то там "видеть". ))
"Формочки" пишутся не просто так, а для обращения к серверу БД или к серверу приложений.
И если "формочка" на VB, то и сервер приложений тоже исключительно на VB, ес-но.
Тут зеркально.
Поэтому, твои "только формочки" смешны. Ты не в теме.
На плюсах тогда писали те COM-поненты, которые требовали некоей эффективности.
Вот, контролы-гриды или OLEDB-провайдеры или какие-нить кодеки.
А сверху клеем на самом большом рынко ПО того времени — в США, был, считай, в основном VB.
Ему составляли конкуренцию только VBA и VBS, ы-ы-ы, как грится.
G>Мне теория не интересна.
Это я заметил еще в 2008-м году, когда ты эпично засветился незнанием спецификаций CLI.
G>В теории бывает столько всего, что не случается на практике в силу многих причин.
Ты решил себя добить?
Говори уже прямо — знания вредят.
G>Мне скорее интересны эти причины, потому что они показывают как реально работают технологии, а не теоретические изыскания.
Реально все 90-е конкуренту DCOM не было от слова совсем. На нём всё жило, если речь шла о серверах приложений, а не просто клиент-сервер, где сервер сугубо СУБД. Хотя и в последнем случае VB был весьма востребован. Тогда редко встретишь IP-сетку, в основном были внутренние сети NetBEUI или IPX/SPX.
В те времена народ даже организовал целый консорциум CORBA, чтобы придумать альтернативу тотально монопольному DCOM, но пока они раскачались, уже началась Джава, а потом и Дотнет. Не успели.))
Это как оно было в нашей реальности, а не в твоих странных её ощущениях.
Просто тут народ по-большей части писал на дельфях, поэтому был не востребован на фрилансе на буржуев и в среднем понятия не имел о раскладе сил среди технологий того времени. А я пофрилансил в своё время достаточно. Штукарь баксов в месяц в конце 90-х в нашей провинции, знаешь ли, деньги были невиданные. Тогда и по Москве больше 600 платили редко. ))
V>>Но в этих системах отродясь серьезного С++ никогда не было. V>>Ну кроме той тонкости, что "движок" таких систем был писан на С++, ы-ы-ы. G>На каждый Access приходилось по несколько десятков самописной фигни на C++.
Брехня.
Если речь шла о заказухе, то на С++ всю жисть писали лишь критичные к эффективности библиотеки-компоненты или простое клиентское GUI, вместо VB — когда нужно было хостить OLE-документы в приложухе.
G>Потом пришла java и всю фигню начали писать на Java.
Начали пробовать. Быстро поняли, что для GUI оно не катит.
V>>Поэтому, твоё исходное утверждения якобы о том, что Джава потеснила С++ — оно дилетанское, ангажированное. G>Ты хочешь сказать не потеснила?
Практически нет.
Я, вроде бы, довольно четко описал, какие технологии потеснила Джава.
G>Доля кода, написанного за деньги на Java росла как раз за счет доли C++.
Так вот в каком болоте живут и размножаются эти мифы, ы-ы-ы.
G>Все твои рассказы про access тут никаким боком.
Был упомянут не только Access.
G>У нас тот же самый путь с 1995 по 2005 был у Delphi.
Именно что. Джава потеснила Дельфи, VB и кучу других таких же приблуд.
Ну как потеснила? — это одни и те же люди перешли с Дельфи на Джаву или на Шарп.
До потеснения С++ у джавы ручки коротки — мне сложно представить С++ программиста, который полностью перелезет на Джаву или Шарп.
Это натуральный downgrade.
V>>А сервер Exchange на чем написан? G>На .NET, кроме пары компонент.
ЧТД. Не знаешь, а говоришь.
Как и IIS — он внутри нейтивный.
Дотнетные там плагины, как ASP.Net плагин к IIS, или всякие управляющие веб-"морды"-плагины к функциональности Exchange.
Но системная Exchange Management Console — всё еще нейтивная.
Так же как утилиты командной строки.
Как и сами сервайсы виндов, запускаемые в основных ролях Exchange — там дотнетом и не пахло никогда.
Далее.
Все эти технологии репликации, в том числе асинхронной, все кластерные вещи — всё это нейтивное.
В 2010-м году Exchange перешел на технологию DAG, которая, внезапно, тоже всё еще нейтивная.
Дотнетной может быть только некая тонкая обертка вокруг неё.
А это 2010-й год, заметь, ты уже перешёл тогда на дотнет, а Exchange — нет.
Вот тебе цена твоим словам.
Ты не только не в курсе технологий 90-х, но и технологий 2000-х.
G>Как раз наоборот. Плюсы бывают по историческим причинам в малом количестве.
Ну да.
Все серваки, все ОС, все сервисы — все написано на плюсах.
Даже дотнет и v8.
Любые игровые фреймворки, даже Unity, который некоторые нубы всерьёз считают дотнетным, ы-ы-ы.
V>>Одно время были популярны Tomcat, JBoss, но их популярность резко стала снижаться уже в конце 2000-х. V>>Системы на таких платформах — они одноразовые, не коробочные нифига. G>Ты же понимаешь, что в заказной разработке денег больше, чем в продуктовой?
Для менеджера — да. Потому что надо "впарить и загрести бабла".
Для разработчика — ровно наоборот.
Набирают обычно всякий неопытный сброд, текучка в таких конторах сумасшедшая.
G>В смысле программист может заработать, а не компания, продающая продукт.
Пока что я вижу вакансии у таких контор резко ниже того уровня, который лично меня бы устроил.
В таких конторах хорошо набираться опыта, когда ты вчерашний студент и у тебя стаж менее 5-ти/7-ми лет.
Но если захочется далее вырасти не в менеджера, а в профессионала, сделать карьеру и получать достойную зарплату, то в таких конторах путей для этого банально нет.
G>Именно для заказной разработки имеет смысл повышать продуктивность, а не для продуктовой.
Продуктивность на жабе, шарпе и особенно на JS сегодня уже никого не впечатляет, а местами сильно отстаёт.
Гугл утверждает, что у него по замерам продуктивность на том же Darte получилась намного выше, чем на JS.
Согласно замерам Гугла, стоимость поддержки решений на JS растёт экспоненциально с размером кодовой базы.
Для С++ — ровно наоборот.
Чем больше накапливается библиотек, тем дешевле поддержка целевых продуктов.
В этом суть статически-типизированных языков.
И в этом смысле JS был, есть и будет гирей на ногах.
V>>В коробочном мире рулит нейтив. G>Подавляющее большинство (больше 95% точно) корпоративных систем уже 10+ лет на managed языках написано. Это я про коробочные как раз.
Угу, особенно 1C. ))
Любые корпоративные системы, где функциональность как в 1С можно допиливать неким кодом/скриптом — они нейтивные.
А где решения "стандартные" — те медленно но верно дохнут, потому что переезжают на модель "ERP как сервис".
Потому что смысла в "коробке" уже немного — её дорого содержать/администрить, дешевле воспользоваться сервисом.
G>Софт для телефонов пишется на Java, iOS, .NET\Xamarin. Из них нативный только iOS с натяжкой.
iOS без натяжки хардкорно нейтивный.
Андроид всю дорогу тормозил и был высмеиваем, поэтому побирался в дешевых телефонах начального уровня.
Но пару лет назад Гугл перевёл Андроид на AOT-компиляцию.
Так вот, возвращаясь к нашим баранам — никакая AOT-компиляция не спасёт JS, потому что для KS она невозможна.
Я вообще ХЗ, чего ты тут так рьяно пытаешься мочиться против ветра? ))
Именно Гугл, производитель Андроида и v8 (ты не обратил внимания, что эти проекты Гугл начал синхронно когда-то?), хорошо понимает недостатки JS, поэтому именно он продвигает альтернативные технологии: NaCL, WebAssembly, Dart.
Но ты же умнее Гугла, верно?
Знания вредят, так? ))
Здравствуйте, gandjustas, Вы писали:
V>>Впечатление такое, что TS — это чуть продвинутый JS, а Dart — это чуть продвинутый TS. G>И оно неправильное. G>TS это JS+типы.
— ты куда, в баню?
— да нет, в баню!
G>Любой код на JS превращается в TS путем добавления аннотаций, чтобы удовлетворить компилятор.
А мама мыла раму.
(С) Букварь.
G>Dart — отдельный язык, который не похож на JS своими правилами и идиомами.
Как раз идиомами похож, похож АПИ системных библиотек (практически слепок с либ JS), а не похож лишь синтаксисом, т.к. аннотации типов сделаны в стиле C/C++/C#.
G>Изначально Angular2 писали на AtScript, который внезапно оказался очень похож на TS. Послы доброй воли пришли в гугл и уболтали не рожать еще один язык, а писать на TS. В TS специально для этого ничего не добавляли.
Учите матчасть.
TS был доработан до "понимания" AtScript.
G>Dart появился потом.
Учите матчасть.
TS был представлен в 2012-м, а Dart — в 2010-м.
V>>Вот теперь всё сошлось, в итоге у Гугла появился конвертер из TS в Dart: V>>https://github.com/angular/ts2dart G>Это сделали чтобы не переписывать Angular2 на дарт руками.
Ага, а ветер дует от того, что деревья качаются.
Слушай, а ты забавный...
Ладно, дальше даже не читал, сорри.
Такое большое количество мифов и откровенного невежества на квадратный сантиметр экрана, что всё бессмысленно.
За последние 8 лет ты нифига не вырос, увы.
Но если раньше "молодой специалист" мог требовать заслуженного к себе терпения при объяснении материала, то сейчас уже ой.
Без меня. Оно не в коня корм при таких раскладах. Даказано многократно. ))
Здравствуйте, gandjustas, Вы писали:
G>Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
Ты просто не в курсе, что в том форуме происходит. То, о чем ты пишешь — от скуки: пришел студент с глупым вопросом, и ему отвечают на него буквально, выдумывая разные способы, сами при этом таким не пользуются. А объяснять, что так делать не надо, почему, и как это делают, мало кто хочет: во-первых, это оффтоп, вопрос был конкретный, во-вторых, студенты бывают упертые и им даже стандарт не указ, а в-третьих, сразу набегут с умозрительными ситуациями, когда такое в редком случае могло бы пригодиться. В таких топиках обсуждение очень далеко от реальных подходов к реальным задачам.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>"Формочки" пишутся не просто так, а для обращения к серверу БД или к серверу приложений. V>И если "формочка" на VB, то и сервер приложений тоже исключительно на VB, ес-но. V>Тут зеркально.
На VB в основном клиент-сервер был, сервер — БД в том числе access на файловой шаре, а клиент — VB. У нас вместо VB был Delphi.
Но это из разряда формоклепательства для малого и среднего бизнеса.
V>Поэтому, твои "только формочки" смешны. Ты не в теме.
Если ты в теме, приведи примеры, а не теории.
G>>Мне теория не интересна. V>Это я заметил еще в 2008-м году, когда ты эпично засветился незнанием спецификаций CLI.
Прости, но ты в каждой второй теме чушь говоришь.
V>Говори уже прямо — знания вредят.
Исключительно теоретические знания вредят.
Например твои знания про ректоры и протракторы не помогают тебе в понимании работы nodejs от слова совсем.
V>Если речь шла о заказухе, то на С++ всю жисть писали лишь критичные к эффективности библиотеки-компоненты или простое клиентское GUI, вместо VB — когда нужно было хостить OLE-документы в приложухе.
В данном случае речь про крупняк, типа банков, где наколеночные решения на VB считались моветоном, а аналогичные на java — норм, только пафоса больше. И денег на разработку достаточно. Я например видел такое в РЖД.
V>>>Поэтому, твоё исходное утверждения якобы о том, что Джава потеснила С++ — оно дилетанское, ангажированное. G>>Ты хочешь сказать не потеснила? V>Практически нет. V>Я, вроде бы, довольно четко описал, какие технологии потеснила Джава.
Ты написал про DCOM и CORBA, они вроде как не C++. Тогда на чем были написаны эти серверы? Все на VB?
G>>У нас тот же самый путь с 1995 по 2005 был у Delphi.
V>Именно что. Джава потеснила Дельфи, VB и кучу других таких же приблуд.
У нас в крупняке было такое же засилие C++ (DCOM и прочее), которое потеснила Java. А формоклепство для малого и среднего бизнеса на VB\Делфи жаба потеснить так и не смогла, ни тут, ни там. .NET смог, но это уже было в 2005.
V>До потеснения С++ у джавы ручки коротки — мне сложно представить С++ программиста, который полностью перелезет на Джаву или Шарп.
Даже на этом форуме сотни таких.
V>Это натуральный downgrade.
Это всего лишь инструмент, повышающий продуктивность.
V>Дотнетные там плагины, как ASP.Net плагин к IIS, или всякие управляющие веб-"морды"-плагины к функциональности Exchange.
Там почти все managed кроме поиска.
V>Но системная Exchange Management Console — всё еще нейтивная. Она с 2013 года в вебе
До 2013 версии в Exchnage действительно было много нейтива.
V>Так же как утилиты командной строки.
С 2013 года на PowerShell.
V>Как и сами сервайсы виндов, запускаемые в основных ролях Exchange — там дотнетом и не пахло никогда.
Кроме поиска все managed
Лучше пойди изучи вопрос.
V>Далее. V>Все эти технологии репликации, в том числе асинхронной, все кластерные вещи — всё это нейтивное.
Уже managed.
V>В 2010-м году Exchange перешел на технологию DAG, которая, внезапно, тоже всё еще нейтивная.
Уже нет
V>Ну да. V>Все серваки, все ОС, все сервисы — все написано на плюсах. V>Даже дотнет и v8. V>Любые игровые фреймворки, даже Unity, который некоторые нубы всерьёз считают дотнетным, ы-ы-ы.
И че? Все равно здравый человек будет писать на том, что дает максимальную продуктивность. И это будет не C.
V>>>IIS, ngix, Apache — везде плюсы. G>>Ты сравниваешь серверы и приложения? V>Я сравниваю технологии.
Опять теоретизируешь, понятно.
G>>Ты же понимаешь, что в заказной разработке денег больше, чем в продуктовой? V>Для менеджера — да. Потому что надо "впарить и загрести бабла".
Для программиста тоже.
V>Для разработчика — ровно наоборот.
Суммарные затраты на разработку в заказухе больше, чем в продуктах. Программист потенциально может заработать больше. Дальше уже спрос, предложение и умение продать себя.
V>Набирают обычно всякий неопытный сброд, текучка в таких конторах сумасшедшая.
Это от конторы зависит. Я в продуктовых видел текучку и видел в заказухе команды, которые существуют много лет.
G>>Именно для заказной разработки имеет смысл повышать продуктивность, а не для продуктовой. V>Продуктивность на жабе, шарпе и особенно на JS сегодня уже никого не впечатляет, а местами сильно отстаёт.
По сравнению с чем?
V>Гугл утверждает, что у него по замерам продуктивность на том же Darte получилась намного выше, чем на JS. V>Согласно замерам Гугла, стоимость поддержки решений на JS растёт экспоненциально с размером кодовой базы.
Странно было бы если бы гугл утверждал обратное.
V>Для С++ — ровно наоборот.
Да не заливай. Такого бреда я давно не видел.
V>Чем больше накапливается библиотек, тем дешевле поддержка целевых продуктов.
А при чем тут размер кодовой базы?
V>В этом суть статически-типизированных языков.
Это ты чушь какуюто сказал.
V>И в этом смысле JS был, есть и будет гирей на ногах.
Тот JS, про которы ты говоришь (образца 93 года) — да. Современный — нет.
V>>>В коробочном мире рулит нейтив. G>>Подавляющее большинство (больше 95% точно) корпоративных систем уже 10+ лет на managed языках написано. Это я про коробочные как раз.
V>Угу, особенно 1C. ))
1С это платформа, а сама программа (конфигурация) пишется а vb-подобном языке.
V>Любые корпоративные системы, где функциональность как в 1С можно допиливать неким кодом/скриптом — они нейтивные.
Ага, Axapta или navision, которые как раз mamanged. Не выдавай желаемое за действительное.
G>>Софт для телефонов пишется на Java, iOS, .NET\Xamarin. Из них нативный только iOS с натяжкой. V>iOS без натяжки хардкорно нейтивный.
Я чето неточно написал. На iOS два языка, нативный Objective-C и вполне себе managed swift.
V>Так вот, возвращаясь к нашим баранам — никакая AOT-компиляция не спасёт JS, потому что для KS она невозможна.
Это ты вообще к чему сказал? JS и без AOT нормально работает (всех устраивает).
V>Я вообще ХЗ, чего ты тут так рьяно пытаешься мочиться против ветра? )) V>Именно Гугл, производитель Андроида и v8 (ты не обратил внимания, что эти проекты Гугл начал синхронно когда-то?), хорошо понимает недостатки JS, поэтому именно он продвигает альтернативные технологии: NaCL, WebAssembly, Dart.
NaCL, Dart уже сдохли, первый похоронили официально, второй пытаются насильно поднять из могилы.
WebAssembly — взлетит, будет прекрасно. Но пока новости не обнадеживающие.
G>>Изначально Angular2 писали на AtScript, который внезапно оказался очень похож на TS. Послы доброй воли пришли в гугл и уболтали не рожать еще один язык, а писать на TS. В TS специально для этого ничего не добавляли.
V> V>Учите матчасть. V>TS был доработан до "понимания" AtScript.
Ты подробнее вопрос изучи для начала.
В AtScript были аннотации. В ES не было аннотаций, предложение было на ранней стадии. В TS согласились добавить аннотации в формате AtScript пораньше, чтобы разработка Angular2 велась на TS. Когда в стандарте ES проработали аннотации, то в TS и Angular2 стали использоваться аннотации ES.
G>>Dart появился потом. V>TS был представлен в 2012-м, а Dart — в 2010-м.
Я говорю что Angular2 dart появился позже перехода на TS.
V>>>Вот теперь всё сошлось, в итоге у Гугла появился конвертер из TS в Dart: V>>>https://github.com/angular/ts2dart G>>Это сделали чтобы не переписывать Angular2 на дарт руками.
V>Ага, а ветер дует от того, что деревья качаются.
Понятно, сказать по теме нечего, гуляй.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, gandjustas, Вы писали:
G>>Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
Ops>Ты просто не в курсе, что в том форуме происходит. То, о чем ты пишешь — от скуки: пришел студент с глупым вопросом, и ему отвечают на него буквально, выдумывая разные способы, сами при этом таким не пользуются. А объяснять, что так делать не надо, почему, и как это делают, мало кто хочет: во-первых, это оффтоп, вопрос был конкретный, во-вторых, студенты бывают упертые и им даже стандарт не указ, а в-третьих, сразу набегут с умозрительными ситуациями, когда такое в редком случае могло бы пригодиться. В таких топиках обсуждение очень далеко от реальных подходов к реальным задачам.
А потом спустя 5 лет студент, знающий что можно возвращать staic приходит на форум и начинает такое всем рекомендовать.
Кстати почему подобного не наблюдается в форуме .NET? Там на любой простой вопрос тебе прилетит исчерпывающий ответ.
Здравствуйте, vdimas, Вы писали:
V>Потому что в TS параметрического полиморфизма нет, есть "шаблоны" — синтаксический сахар, а не система типов. V>В C# параметрический полиморфизм тоже не полноценен — он не отличает типы аргументов по их ограничениям.
Опять же TS это прежде всего интеллсенсе и статическая проверка. Ты же все напираешь на статическую типизацию для компиляции.
А для этого нужен свой Фреймворк в браузере.
А для этого и .Net Core прекрасно подойдет. MS вполне мог бы такой браузер сделать. Я так понимаю Visual Studio Code это по сути браузер?
На данный момент у Dart нет никаких премиуществ перед TS. Кстати я бывший дельфист, но больше программирую на C#. Для меня TS дается легко, а если будет транслятор из C# в TS (а может он и есть), то многие вещи не сложно перетащить
и солнце б утром не вставало, когда бы не было меня
/operator-overloading-js S>>через прототипы
V>Операторы можно перегружать только в типизированном контексте, а не в контексте связки объекта/прототипа. V>Потому что концов не словишь — где и откуда растут ноги. ))
Там основной пример это вызов перегрузки операторов удаленных объектов по Tcp/Ip.
То есть мы работаем по снтаксису с удаленным объектом как с родным.
To AndrewVK ссылка дана к контексте обсуждения перегрузки операторов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
V>>node.js помимо всего прочего, что операции ввода-вывода для каждого отдельного файлового хендла будут привязаны к одному и тому же потоку. G>Ты не в курсе что node однопоточный?
Я ХЗ, расписывать ли тебе работу реактора для ситуации, когда файловый хендл привязан только к одному обслуживающему потоку или сразу к нескольким.
G>Даже коллбеки попадают во внутренний event loop и обрабатываются одним потоком. Это и на сервере и на клиенте.
Я дал тебе вполне конкретную ссылку на юмор.
Там в конце есть ссылка на "статью" от коллеги.
Сама статья была написана коллегой из-за непонимания принципов работы node.js.
Знаний об "однопоточности" мало в асинхронном фреймворке.
Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.
В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
V>>Тут на сайте был разбор примеров, где это имело значение (разбирал я с Ikemefula). Т.е., человек работает с языком, а что там на самом деле происходит — понятия не имеет. G>Пока что ты показываешь, что понятия не имеешь про современный JS.
Пока что ты показываешь непонимание вообще ничего.
Как и 8 лет назад.
Причем, я твоё непонимание показываю в каждом сообщении, а ты всё обещал показать моё — но так и не смог.
V>>С++ бъет по рукам за ошибки, вызванные непониманием происходящего. G>И большинству это не помогает. Люди находят workaround и пользуются им всю жизнь, так и продолжая не понимать суть.
Ну это про маньяков каких нить. ))
Люди просто уходят на другие технологии, если им неохота разбираться в подробностях.
G>Вот недавно захожу в раздел C++ на форуме, а там совершенно искренний вопрос как вернуть char* из функции. И половина советует делать static.
Ссылка?
А то без контекста тут можно говорить о чем угодно.
Половина спрашивающих на форуме С++ — это студенты или вчерашние студенты.
И молодцы что спрашивают! ))
V>>Я уже всё сказал: V>>
V>>Я так думаю, что программист с ростом должен уметь решать всё более сложные задачи.
G>Как это связано с языками? Сложные задачи могут быть на любом языке.
Не на любом.
Если для node.js на C++ не напишешь АПИ на некую нейтивную функциональность, то вот уже и нет решения на JS.
JS как язык внутри пуст как абстрактное зеро.
Вся его полезная функциональность поставляется нейтивным хостом или нейтивными же "обертками"-библиотеками над имеющимся плюсовым кодом.
В этом смысле JS — классический клей, как VB когда-то.
С одним отличием — на VB писали быстро и поддержка была проектов на нём была дешевая, бо ему указал пару директив (строгая типизация, обязательное объявление переменных) — и всё! Ни одна абстракция никуда не протечет.
Поэтому, на JS сейчас пишут медленно и отлаживаются долго.
И чем больше по размерам проект, тем меньше продуктивность.
Вся "сила" JS — это в доступе к огромному кол-ву JS-кода, накопленного в браузерных технологиях за 20 лет.
В этом смысле node.js — это биокомбинат для утилизации всех этих отходов IT-промышленности.
G>Вполне может оказаться так, что сложная задача на одном языке в другом языке становится примитивной. Поэтому и надо повышать продуктивность и изучать более мощные языки.
А зачем тебе такие языки, которые делают задачи сложными или нерешаемыми?
Система типов того же C++ позволяет описывать код, типа твоего Excel на JS типобезопасно и при этом так же выразительно.
Тут нужен лишь некий eval для формул.
Сам-то eval всегда нейтивный, разумеется, даже в JS. ))
Тут вся фишка типобезопасности в том, что она обеспечивает отсутствие "эффекта засорения" проекта хелперами. Всевозможные хелперы не конфликтуют друг с другом, в отличие от библиотек JS, которые часто портят друг другу жизнь, у которых хромает версионность и такое понятия как "детерминированное АПИ" отсутствует как класс.
V>>Можно научиться быстро работать руками на конвейере, а можно сделать робота вместо десятка таких "ловких на руки" человек. G>Аналогии интеллектуального труда с конвейером сразу идут в мусорку.
Верно, но ты же пытаешься превратить разработку в конвейер, а не в процесс роботизации.
Т.е. ты настаиваешь на навыках шустрого использования "имеющегося" а не разработки нового.
V>>Оформившиеся принципы разработки на С++ — именно такие, заключаются в "роботизации" и это даёт дикий профит. G>Думаешь C++ тут уникален?
Я сравниваю с Джавой, C#, JS.
Я вижу, что средний JS программист может решить только те задачи, под которые есть соответствующий фреймворк/библиотеки.
Точно так же когда-то высмеивали дельфистов, кста.
G>Пока языки имеют примерно одинаковые возможности, то разница заключается в основном в библиотеках.
Верно.
Но еще играет рояль возможность дописать отсутствующую функциональность при надобности.
И тут "примерно одинаковые возможности" порой превращаются в "резко разные".
G>C# первой и второй версии мало отличались от Java и уступали C++ во многом
C# уже в первой бете превосходил доступные библиотеки С++ на пару порядков, если не больше.
Для сравнения — на момент выхода C# платные либы на Джаву стоили 150-250 баксов.
Для плюсов стоимость либ могла быть 800, 1500, 5000 баксов аж бегом в то же самое время.
Да я охренел, собсно, сколько функциональности выкатила MS абсолютно даром в первой же бете дотнета.
Это был натуральный культурный шок.
И пофиг, что язык изначально сильно уступал — зато сколько халявы!
G>Потом появился linq и java с С++ начали отсасывать.
Linq в основном нужен только там, где "формочки".
Потому что прочитать из базы, взять итоги, отсортировать, отобразить.
Вот тебе класс примитивных операций над множествами для формошлёпства или веб-морды.
G>Если бы не андроид и покупка жабы ораклом, то жаба могла бы сдохнуть.
Могла. Потому что C# как язык развивался, а Джава уже нет.
G>Потом то же самое произошло с async\await. Сейчас появился C# 7 с огромной кучей новых фишек для продуктивности. Это конечно не революции типа linq и async, но тоже двигает язык вперёд.
Сегодня язык двигает вперёд больше .Net Core или .Net Native.
Потому что сразу много граней у платформы должны сверкать, ничего не должно тянуть на дно.
V>>Собсно, на сегодня это даже не сравнимо, бо в скорости написания кода C# уже резко отстаёт, хотя еще в 2005-м резко обгонял плюсы. G>Да конечно Ты наверное и C# последний раз году в 2005 видел.
Нет, это ты смотрел на C++ в последний раз в 1998-м.
А я на шарпе упражняюсь регулярно.
И чем дальше, тем больше мне на ём скучно, бо эффект "халявы" уже не тот, не тот...
Ведь всё познаётся в сравнении, верно?
Времена-то изменились.
В общем, как только объем доступных библиотек для плюсов догнал жабку и шарп, так сразу же на плюсах всё стало намного быстрее и проще.
Тут несравнимо от слова совсем, просто ты не в теме.
Там, где мне на шарповом проекте приходилось писать кучу утилит, хелперов и т.д., там на плюсах объем этих хелперов, во-первых, на порядки меньше (исходный код не в пример более повторно применим), во-вторых, сами эти хелперы пишутся быстрее и шире применимы.
G>C# до сих пор самый продуктивный серверный язык. Теперь еще и честно кроссплатформенный.
Есть такая весчь — инерция называется.
Я регулярно смотрю рефлектором или через dotPeek устройство всяких дотнетных библиотек, особенно которые пытаются "окучить" некие технологи — это просто какая-то ж-па. Там реально МНОГО кода на пустом месте. Ну как "на пустом". Он там реально нужен, в этом и заключается звиздец. В случае С++ 90% такого кода НЕ нужно.
Посмотри ради любопытства асинхронный ввод/вывод на сокетах, класс Task и прочее — это же жесть, как она есть.
Горы кода, чтобы выразить простейшие вещи.
В общем, как ни крути, но на C# на одну и ту же функциональность надо больше исходного кода больше траха.
Он показывает свою "силу" только в случае уже готовой некоей функциональности, когда "кто-то другой" уже сделал.
А если эту функциональность надо писать самому — то это застрелиться.
Современные ORM фреймворки для C++ в строках кода уже сильно меньше, чем здешний BLT.
G>Кстати недавно написал небольшой код на C# и .NET Core, заняло полдня примерно. Чувак решил переписать на C++ и через неделю бросил.
Я и на шарпе полно слабых программистов знаю, и?
Причем, их там заведомо больше, и?
V>>Просто посмотри на вот эту библиотеку: http://www.rsdn.org/forum/prj.codejam V>>Для современного С++ ничего подобного уже не нужно. G>Для .NET года с 2005 не нужно.
Эту библиотеку пишут наши .Net-топы с сайта прямо сейчас.
G>при появлении достаточной массы кода на C# команда разработчиков начала тупо смотреть какой код люди пишут и повышать продуктивность написания такого кода.
А чего же у самих так много кода на пустом месте?
Где же живет та самая "продуктивность"? ))
Почему WPF делали 5 лет и он так и не взлетел (заранее рекламировали дотнетный Avalon как GUI-систему для виндов).
Зато его аналог на плюсах выкатили за полтора года и оно летает на виндах от 8 и выше?
Причем, сделали его меньшим числом разработчиков (примерно в 5 раз меньше, чем работало над WPF)?
Тем самым вчистую разбив всевозможные мифы относительно ужасности нейтивной разработки?
Что есть продуктивность, если не потраченные на задачу человекочасы, ы?
За что и погнали, собсно, Великого Липперта ссаными тряпками.
Ведь это он в первой половине 2000-х сильно проповедовал против плюсов, не?
Блог такой вёл, аж зачитаешься...
Ну если не понимать проблематики, конечно и вестись как кролик на развод. ))
Но жизнь-то всё-равно рано или поздно расставила всё на свои места.
Здравствуйте, gandjustas, Вы писали:
G>>>Поэтому проще написать JS и дергать api из браузера, чем писать серверный код. V>>Кошмар )) G>Таковы реалии enterprise разработки.
Это реалии "впаривания".
Подобные задачи на современной 1С решаются лучше и надёжней.
G>А есть еще всякие облачные сервисы, где у тебя нет даже технической возможности написать серверный код.
Ага, с одним "но" — в гугловых облачных серверах не предоставляют node.js.
Зато MS предоставляет. Забавно, не правда ли? ))
Видишь, как много ты рассказал о себе одной фразой.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, vdimas, Вы писали:
V>>Перегрузка операторов — это весьма популярный приём в С++, т.е. фича востребованная, при её наличии. G>Можешь показать примеры перегрузки операторов, кроме случаев: G>1) Математических объектов, когда перегружаются операторы для сложения\умножения векторов\матриц\итд
Это изкаробки был основной кейз. ))
G>2) Перегрузки оператора ->, ()
И это тоже. Смарт-поинтеры и функторы.
В этом смысле в дотнете всё печально — или пиши a.b.c.d.TargetMethod, или пиши делегирующий код на каждом уровне.
А по несовместимой сигнатуре функциональных типов в дотнете не прошелся только ленивый.
G>3) Перегрузки >> и << для потоков
Для чего угодно, для сериализации, форматирования и т.д.
Здравствуйте, Somescout, Вы писали:
S>Значит вам не составит труда привести примеры. А вы, вместо этого уже третье (или второе?) сообщение словоблудием занимаетесь.
Все уже сказано.
I>>Скажи честно, как часто ты пишешь код вида a = a или a === a ? Ну, в твоём любимом ЯП. Интересует статистика. Если ты такое пишешь каждый день, то конечно, все меняет.
S>То есть это не проблема, потому что невелик шанс на неё наткнуться на неё. Интересная точка зрения. Мне не нравится.
Именно. В остальных языках ровно так же, только ты к подобным косякам привык.
I>>Представь себе, JS это самый популярный язык. I>>Миллионы людей каждый день отлаживает код.
S>LOL Миллионы людей в лучшем случае говнокодят, благо js с его широкими возможностями monkey-patching'а к этому располагает.
Ты наверное и C# последний раз году в 2005 видел. C# до сих пор самый продуктивный серверный язык. Теперь еще и честно кроссплатформенный.
