Здравствуйте, 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>За что и погнали, собсно, Великого Липперта ссаными тряпками.
Там же чистая политика, технологии вообще не при чем.
