Здравствуйте, 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-х сильно проповедовал против плюсов, не?
Блог такой вёл, аж зачитаешься...
Ну если не понимать проблематики, конечно и вестись как кролик на развод. ))
Но жизнь-то всё-равно рано или поздно расставила всё на свои места.