Здравствуйте, Ikemefula, Вы писали:
I>>>Так с каждым языком. Если ты на Джаве начнешь писать как на плюсах, язык покажется очень кривым. _>>На Java невозможно писать как на C++, просто по определению. В силу дизайна языка. I>Можно. Посмотри код сиплюсника когда он только-только на джаву пересел, это оно и есть. Первый год сиплюсник не код пишет, а только орёт, что язык говно. На второй уже успокаивается. На третий сам уже гнобит свежеиспеченного джависта-из-плюсов.
Ну приведи хоть один конкретный пример антипаттерна для Java, который при этом был бы характерен для написания C++ кода. Для обратной ситуации я легко могу привести подобный пример.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>> Еще раз TS может прекрасно компилироваться и в .Net IL.
V>Этого мало, надо уметь оперировать возможностями платформы. V>Сможешь ли ты вызвать .Net Interop из TS?
S>>Кстати и C# компилируют в JS. S>>Он тоже стал синтаксическим сахаром?
V>Я уже отвечал на это: V>
V>Я че-то проблематики не улавливаю при переводе из более сильной системы типов в более слабую.
V>А в бинарник нейтива как программы переводятся? Там же вообще типы затираются.
Ну дык с каких пор ассемблер стал типизированным? В данном случае JS это ассемблер.
S>>JS тоже умеет вызывать нативный код.
V>Не умеет. V>Посмотри исходники либ для ноды — что там делается, чтобы этот код стало возможным вызывать из JS.
Я не только могу вызвать натив но и манагед код я же на них тебе давал ссылки. Тот же PNacl, WebAssembly.
Ты почему то проигнорировал.
S>> По поводу перегрузки функций, то она есть S>>https://metanit.com/web/typescript/2.2.php
V>Это не перегрузка, это динамика.
S>>Но из за того, что JS не поддерживат перегрузку приходится делать так S>>Или так V>...
V>Во-во. V>Сам же всё видишь, но споришь ради спора, что ле?
Я не спорю, а привожу то что есть в TS. Там есть перегрузка, но с ограничениями.
Возможно в следующих версиях сделают как в asнnc кодогенерацию.
S>>Насчет динамиков. Динамики нужны там, где заранее не известен тип.
V>Я и на это уже отвечал: V>
V>Эти dynamic нужны исключительно для вызова некоего нетипизированного скриптового АПИ.
V>Дай типизированное АПИ для скрипта+правила автоматического маршаллинга, и никакие dynamic будут не нужны.
S>>Но к нему можно сделать прокси. S>>Например вызов объектов и типов .Net Core из натива и JS через натив, вызов удаленных объектов по TCP/IP? S>>разбор часто меняющихся структур JSON, XML
V>"Частоменяющиеся" — не при чем, у тебя в любом случае код должен уметь работать с той версией, про которую знает. Так вот, эти "знания" вполне себе поддаются типизации.
Надеюсь ты знаешь, что такое утинная типизация? Кроме нужных полей и методов, может быть куча других, а динамики позволяют забить на бинарную совместимость.
Мне всегда нравится как C++ работают с той же 1С через COM IDispatch
V>Про вызов удалённых процедур — аналогично. Первые два десятилетия существования подобных технологий как таковых сами удалённые процедуры вызывались строго типизированным образом через предварительно описанный IDL.
Угу специально делаем типизированные обертки, которые внутри делают то же самое.
Еще раз напомню про IDispatch. Можно сделать универсальную обертку и использовать её. Можно кстати применять аннотацию типа, жалко, что нет аналога в C#. Либо для каждого возможного типа делать свою обертку.
Я так понимаю, ты выбираешь второе.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
I>>Статья, что характерно, демонстрирует описаную тобой проблему.
V>Статья демонстрирует непонимание тобой гарантий, даваемых каждой из моделей асинхронного IO.
Цитирую себя: "Пример демонстрирует тёмную сторону node.js и JavaScript в частности."
Собтсвенно он именно демонстрирует. А вот правильного варианта в ём нет и не будет, пока я не напишу вторую часть статьи.
I>>Фактически, это домашнее задание студентам, найти ошибку. V>И что ж ты сам не нашел?
Я её тебе же уже четвертый год показываю
V>Очевидно, что ты не в курсе того, что IOCP может работать и в режиме реактора — тут достаточно начинать асинхронную операцию с аргументом WSABUF, у которого указана нулевая длина буфера. Тогда мы получим модель асинхронщины аккурат как в линуховом epoll — т.е. будем получать лишь оповещения о готовности IO.
Мы говорим про JavaScript. Не надо увиливать.
>>>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках. I>>Ну теперь то ты сможешь объяснить, почему последовательность выполнения недетерминирована и откуда берутся гонки ?
V>Ну, у меня-то всё строго детерминировано — я показал как этого достичь и подробнейшим образом объяснил происходящее. Там должен быть понять даже студент.
У тебя ничего не получилось, посмотри вывод своего же кода с моим логированием.
Здравствуйте, vdimas, Вы писали:
I>>Цитирую некоего vdimas I>>
I>>Так вот, м/у read и его колбеком не происходит НИЧЕГО
V>Я там же следом для особо понятливых и пояснил — м/у операцией read и её колбэком.
Это ты задним числом меняешь смысл своих слов. Вначале ты махал кулаками и показывал код, который якобы это и демонстрирует. Но код оказался неверным
Именно это ты и хотел продемонстрировать кодом, но не вышло.
V>Ты ДЕЙСТВИТЕЛЬНО не понимаешь, что вызовы read в твоём коде не производит собсно чтения?
И здесь снова меняешь смысл написанного з.
V>Я тебе там же более одного раза пояснил, что ты не можешь знать, происходит ли что-то или нет м/у самой операцией чтения и колбэком, т.е. ты можешь считать, что не происходит ничего. Потому что, у тебя физически нет способа это как-то проверить в коде JS.
Вообще то ты взялся показать это кодом. И попытка оказалась неудачной.
V>Ох... V>Получается так, что ты до сих пор считаешь, что если ты вывел в лог некий текст "read 26", то у тебя действительно происходит чтение?
Ты перевираешь ранее сказаное.
V>Если бы вот это было верно:
I>>между read и его колбеком проходит время и здесь может отработать сколько угодно других функций.
V>У нас бы довольно быстро read/write стали бы идти вперемешку. Но этого не происходит — строго 5 одних, потом 5 других, как они и были запущены изначально. JS работает как часы, браво!
И ты эти утверждения "продемонстрировал" кодом. Я всего лишь добавил логирование, что бы показать ошибку в твоих рассуждениях. Опаньки!
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>Еще раз напомню про IDispatch.
V>Ты зашел на 3-й круг уже. V>IDispatch изначально был нужен как раз для вызова скриптов и вызова нейтива из скриптов.
IDispatch удобен как раз в том, что можно делать универсальные обертки не привязываять к типам.
То есть сделали один раз универсальную обертку. Это относится и к 1С, WCF, Web Api.
И вот языки с поддержкой динамики здесь выигрывают. При этом не особо проигрывая в скорости https://www.slideshare.net/yu5k3/dlr-54012646
То есть ищется скомпилированные метод по типу. Такой себе типизированныйподход в динамике.
А вот кстати анотацию типов ты проигнорировал. Она очень полезна для динамических языков для интеллисенсе.
Я в свое время генерил диспинтерфейсы для Delphi при работе с 1С. Это по сути и были аналоги аннотации типо, только еще и увеличивали скорость, за счет отсутствия метода GetIDsOfNames
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Философ, Вы писали:
Ф>Кстати, каким профайлером пользуешься? А есть какие-нибудь профайлеры памяти?
"Память — не ресурс!" (С) Сами_знаете_кто
Здравствуйте, Serginio1, Вы писали:
S>IDispatch удобен как раз в том, что можно делать универсальные обертки не привязываять к типам.
Неудобен.
S>То есть сделали один раз универсальную обертку. Это относится и к 1С, WCF, Web Api.
Опять неудобен.
В 1С нетипизированный скриптовый язык, потому что целевая аудитория программистов-разработчиков "конфигураций" делает кучи ошибок, но втюхивать "это" как-то надо.
Ты заставляешь меня озвучивать банальности. Программа на скрипте отличается от программы на компиллируемом языке тем, что первая может хоть как-то исполняться даже будучи невалидной. Программа же на компиллируемом языке не сможет ничего исполнять, пока в ней будут ошибки компиляции.
S>И вот языки с поддержкой динамики здесь выигрывают.
Проигрывают и уже давно.
Они выигрывали раньше, потому что для компиллируемых не было поддержки IDE.
В отсутствии поддержки IDE рулил подход REPL, ОК.
В присутствии же нормальной IDE такой подход становится нелеп, архаичен, подлежит списанию в утиль.
Тут даже плевать на скорость.
Программа-то целиком невалидна на скрипте, а ты и не знаешь.
Только по ошибкам в рантайме и видно.
S>А вот кстати анотацию типов ты проигнорировал. Она очень полезна для динамических языков для интеллисенсе.
И опять ты на сотый круг заходишь по одному и тому же?
Разве это не хамство — аппелировать к неким аргументам, на которые тебе уже отвечали?
Это крайнее неуважение к себе и коллегам.
Я уже отвечал тебе, что до тех пор, пока такая аннотация опциональна, это всё равно, что её нет.
Ты должен отвечать на встречные аргументы, а не продолжать повторять свои, иначе получается та самая неадекватность/невменяемость.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>IDispatch удобен как раз в том, что можно делать универсальные обертки не привязываять к типам.
V>Неудобен.
S>>То есть сделали один раз универсальную обертку. Это относится и к 1С, WCF, Web Api.
V>Опять неудобен. V>В 1С нетипизированный скриптовый язык, потому что целевая аудитория программистов-разработчиков "конфигураций" делает кучи ошибок, но втюхивать "это" как-то надо.
V>Ты заставляешь меня озвучивать банальности. Программа на скрипте отличается от программы на компиллируемом языке тем, что первая может хоть как-то исполняться даже будучи невалидной. Программа же на компиллируемом языке не сможет ничего исполнять, пока в ней будут ошибки компиляции.
Я то пишу на ней. Кстати там какая никакая а есть поддержка интеллисенсе.
S>>И вот языки с поддержкой динамики здесь выигрывают.
V>Проигрывают и уже давно. V>Они выигрывали раньше, потому что для компиллируемых не было поддержки IDE. V>В отсутствии поддержки IDE рулил подход REPL, ОК. V>В присутствии же нормальной IDE такой подход становится нелеп, архаичен, подлежит списанию в утиль.
Угу. При этом питоном бользуется большая часть сишников. S>>При этом не особо проигрывая в скорости https://www.slideshare.net/yu5k3/dlr-54012646
V>Тут даже плевать на скорость. V>Программа-то целиком невалидна на скрипте, а ты и не знаешь. V>Только по ошибкам в рантайме и видно.
Конечно, я же 1С ник. И у меня ничего не работает
S>>А вот кстати анотацию типов ты проигнорировал. Она очень полезна для динамических языков для интеллисенсе.
V>И опять ты на сотый круг заходишь по одному и тому же? V>Разве это не хамство — аппелировать к неким аргументам, на которые тебе уже отвечали? V>Это крайнее неуважение к себе и коллегам. V>Я уже отвечал тебе, что до тех пор, пока такая аннотация опциональна, это всё равно, что её нет. V>Ты должен отвечать на встречные аргументы, а не продолжать повторять свои, иначе получается та самая неадекватность/невменяемость.
То есть TS не нужен, Ты расписываешь про типизацию, но если она опциональна, то есть она и не нужна!!
При этом большая часть ошибок ловится на стадии даже не компиляции в отличие от С++, а на стадии проектирования. Ускоряется безошибочный ввод кода.
и солнце б утром не вставало, когда бы не было меня
тест, то PyPy выдаёт в нём 24,8 мс, что в 1,6 раза хуже результата JS. В том же тесте C# выдаёт в точности такую же разницу по отношению к Java. Означает ли это, что можно сказать, что C# — это убогий тормоз по сравнению с Java? )))
Судя по твоим предыдущим "тестам", от тебя ожидать можно всего угодно. Как то так.
_>Да, и если разница в 1,5 раза — это убогий тормоз, то интересно как тогда ты охарактеризуешь результаты всех остальных языков по отношению к результату C++?
Здравствуйте, gandjustas, Вы писали:
V>>Т.е. ты по ссылке не ходил? V>>А там вполне конкретная задача разбиралась. G>Задача по ссылке не относится к тому что ты писал.
Врешь.
V>>Так вот, разбиралась задача чтения из файла в случае асинхронщины. V>>У коллеги получалось так, что колбэки от асинхронных операций приходили не в той последовательности, в какой инициировались. V>>И это нормально для того же overlapped io в виндах, когда мы инициируем более одной асинхронной операции над хендлом, обслуживаемым через IOCP на пуле потоков. G>Проблема не в порядке прихода коллбеков, а в том, что чтение и запись файла — неатомарные операции.
Во-о-о-от.
Атомарность интересует только при многопоточности.
Итого, node.js многопоточен, а ты ошибался.
G>Гораздо интереснее ситуация если ты читаешь и пишешь память в коллбеках.
Нет, не интересно.
G>Когда у тебя несколько потоков, то можно получить гонку на простом инкременте, в случае одного потока, как в NodeJS — нельзя.
Потому что инкремент выполняется только в потоке выполнения JS, а ввод-вывод имеет право выполняться в произвольном потоке.
На сегодня node.js лишь гарантирует только строгую последовательность колбэков операций для одного хендла, т.е. приход их ровно в том порядке, в каком они были инициированы. Для независимых файловых хендлов приход таких колбэков независим.
V>>Вот тебе вполне конкретная задача, где знания о потоковой модели оказались важны. G>От потоковой модели оно вообще не зависит. Используя один хендл ты сделал чтение и запись файлов атомарными операциями.
Overlapped IO слышал, не? ))
Тоже вполне себе распространённая модель, самая эффективная на сегодня.
Там колбэки от последовательности инициированных асинхронных операций над одним и тем же хендлом могут придти в произвольном порядке.
G>Точно. Ты многопоточность от атомарности не отличаешь
Я хорошо понимаю, что в случае однопоточности отпадает вопрос атомарности.
Предлагаю и тебе начать это понимать.
G>>>Есть один поток выполнения V>>Есть поток выполнения колбэков одного JS-скрипта. G>Это один поток, в котором выполняется весь код, другого нет.
И опять ошибка. Потоков исполнения кода несколько. Просто каждый конкретный контекст исполнения привязан лишь к одному потоку.
V>>Вот в очередь к этому контексту исполнения и копируются колбэки из других потоков. G>Каких "других потоков"? Node нет "других потоков".
Ну запусти процесс, начни активное асинхронное IO да посмотри кол-во его потоков через какой-нить системный монитор.
V>>В JS модульности нет и не спорь, бо это дилетанство как оно есть. G>Я requirejs использовал в 2009 году, вполне себе модули. В node всегда были commonjs модули.
Пофиг когда. Никакие фичи языка от 2009-го года для этого не требовалось, точно так же можно было сразу же, еще в 90-е, т.е. язык вполне себе позволял написать такие же либы. Я же говорю — ты не знаешь язык JS.
V>>Потому что я хорошо знаю, как эмулируется модульность в библиотеках JS — этот трюк прост, как и способы его обхода (даже случайного). G>Что ты имеешь ввиду?
Я имею ввиду трюк замыкания текущего контекста исполнения ф-ии в JS с возможностью этот контекст подать наружу в виде обычного JS-объекта.
Да, чрез этот трюк организована эмуляция модульности.
Но это не означает, что модульность присутствует в самом языке.
А то у тебя уже двойные стандарты получаются: для случая рефкаунтинга ты отвергаушь его автоматизацию через библиотеки, а тут в друг наличие неких JS библиотек приравниваешь к обретению языком неких св-в.
V>>Т.е. из-за ошибки программиста в стороннем модуле вся эта "модульность" может улететь к чертям собачьим. G>Приведи пример чтоли. Вот ты сослался на модуль fs, покажи как "модульность" улетит куда-нить.
Сэмулируй вот такую ошибку:
— подай в ф-ию из модуля №1 экспортированный контекст модуля №2.
— убедись, что в ф-ии модуля №1 можно перезаписать экспортируемые символы из модуля №2.
Ошибка эта распространённая, потому что защиты от неё НЕТ.
И что характерно, что всё может даже долго работать, как и задумывалось, т.е. можно писать в контекст другого модуля и читать из него, думая, что читаешь и пишешь в свой некий объкт, угу. Такое будет работать до тех пор, пока не возникнет конфликта имён или пока конфликтующий символ из модуля №1 был не нужен.
G>Вот тебе код модуля (на TS), поломай в нем модульность:
Детсад, ясельная группа:
var m;
(function (m) {
function internal() { return 0; }
function external() { return internal(); }
m.external = external;
})(m || (m = {}));
alert(m.external);
m.external = 1;
alert(m.external);
Ты еще на невозможность повторить Excel не ответил, кста.
Не успеваешь обсыхать.
G>Да я тебя уже носом тыкнул в десяток ошибок
Я не вижу тыкания.
Я вижу от тебя ошибочные утверждения про модульность в JS.
Т.е., во-первых, это не "десяток", во-вторых, ты не можешь подтвердить свою т.з. через сугубо технические аргументы, а я это сдела уже многократно.
Ты просто упрям.
G>>>Это про подавляющее большинство программистов. V>>По себе других не судят. G>Я сужу по тому, что пишут на форумах.
Из сотен хорошо знакомых мне коллег на форумы никто не пишет.
V>>Средний уровень спрашивающих? G>Сегодня он спрашивает, а завтра отвечает на подобные вопросы.
Это более чем нормально, если он разобрался с вопросом.
Только так знания и передаются.
V>>Я тебя расстрою — почти вся функциональность node.js нейтивная. V>>Я имею ввиду основные его JS-либы. V>>Это всё обертки. G>И что?
Показал твою очередную ошибку.
G>Они уже есть, их писать не надо
1. Надо.
2. Поэтому их активно пишут.
G>бери и используй. Для этого не надо знать C++.
Для этого надо ограничить круг решаемых задач ровно теми, под которые "кто-то" уже написал для несостоятельного тебя либу.
V>>Тем не менее, для прокидывания такой функциональности надо быть нейтивным спецом явно посерьезнее, чем спрашивающий на форуме по ссылке. V>>Получается, ты сам себе противоречишь. )) G>А также говорю, что уровень C++ программистов не обязательно достаточный чтобы решать на нем C++ задачи, которые легко решаются на Node. G>Где ты увидел противоречие?
Выделил.
Там требуется ХОРОШЕЕ понимание происходящего.
Т.е. некие квалифицированные программисты должны обслуживать стадо обезъянок под node.js
V>>>>JS как язык внутри пуст как абстрактное зеро. G>>>Что значит "внутри пуст"? Какой яызк внутри непуст? V>>С++, C#. V>>Оба умеют работать с АПИ ОС, т.е. оба могут реализовать любую востребованную функциональность. G>Путем написания оберток над АПИ ОС, как и в JS.
Без оберток, напрямую.
V>>Может и делает. Например, в драйверах обращается к специальным участкам отображенной на DMA памяти, пишет в порты ввода-вывода. G>Драйверы на C++?
Именно.
Это на порядки удобнее, чем на голом С.
G>Где такую траву берешь?
Не хамите, юноша, вы далеки от темы настолько же, насколько наша галактика от соседней.
V>>>>Поэтому, на JS сейчас пишут медленно и отлаживаются долго. G>>> На JS пишут и отлаживают быстрее, чем на C++ V>>Это уже сильно устаревшая информация. G>Доказательство? G>Может покажешь Excel в 30 строк на C++, предположив, что есть DOM API для C++?
Даёшь мне заголовки этого DOM я тебе даю клиентских код под него, какие проблемы-то?
А то ты как-то всё больше начинаешь быть похожим на любителя халявы "а сделай мне то, а сделай мне это".
V>>На проектах С++ и C# это ровно наоборот. Чем больше накапливается хелперов, чем более высокоуровневой получается "платформа" конкретного приложения, тем выразительней получаетсяя целевой код и тем проще его поддерживать. G>Палишься, у тебя не было крупных и сложных проектов.
Боюсь, ты не знаешь, что такое крупный проект.
В заказухе таких не бывает по-определению.
V>>Сам сижу на большом нейтивном проекте уже несколько лет и вижу, что его с каждым годом всё проще развивать, по мере накопления собственных библиотек. G>Это вовсе не от накопления хелперов, а от того, что со временем скорость появления новых задач падает.
Скорость появления новых задач только растёт. Просто их становится всё проще и проще решать.
Это законы развития IT как такового: скорость появления задач и скорость их решения со временем только растут.
Т.е., именно поэтому JS г-но, что он не удовлетворяет этим фундаментальным требованиям IT — проекты на нём ВСЕГДА демонстрируют деградацию скорости роста. Поэтому гугл в своих внутренних разработках и начал сломя голову убегать от JS.
V>>Потому что, повторюсь, в строго-типизированной среде не происходит "засорения" пространства имён, не происходит засорения перегруженных сигнатур ф-ий и т.д. А в JS можно убить любую ф-ию через создание одноимённой переменной. Или просто переопределить уже имеющуюся и знать никто не будет. )) G>Я тебе уже привел пример с модулем, "убей" функцию internal путем создания переменной вне модуля. G>Как получится — возвращайся.
Детсад, ясельная группа.
V>>И я не утверждаю, что нет ср-в борьбы с этим — вот, эмуляция модульности, к примеру. V>>Но я вижу, как легко программисты ломают все эти сугубо вербальные гарантии. V>>Не специально ломают, ес-но, в этом и проблема. G>Ты настолько не в теме, как писать на js, что дальше нет смысла общаться.
Не надо мне рассказывать, как на нем НАДО писать, ты мне расскажи, какая там есть защита от "как не надо".
G>Как сломаешь модуль добавлением переменной вне модуля — приходи.
Здравствуйте, alex_public, Вы писали:
I>>Можно. Посмотри код сиплюсника когда он только-только на джаву пересел, это оно и есть. Первый год сиплюсник не код пишет, а только орёт, что язык говно. На второй уже успокаивается. На третий сам уже гнобит свежеиспеченного джависта-из-плюсов.
_>Ну приведи хоть один конкретный пример антипаттерна для Java, который при этом был бы характерен для написания C++ кода. Для обратной ситуации я легко могу привести подобный пример.
Не смеши люди. Именно разница в дизайне и создаёт проблемы. С++ девелопер при попытке пересесть на джаву превращается в абсолютного новичка. Такому надо учиться использовать эффективно GC, встроеные кеши, интинсики и прочие тонкости. Числа сравнивать и то надо уметь
тест, то PyPy выдаёт в нём 24,8 мс, что в 1,6 раза хуже результата JS. В том же тесте C# выдаёт в точности такую же разницу по отношению к Java. Означает ли это, что можно сказать, что C# — это убогий тормоз по сравнению с Java? ))) I>Судя по твоим предыдущим "тестам", от тебя ожидать можно всего угодно. Как то так.
Вообще то как раз именно этот тест подробно разбирался на форуме, в том числе и вместе с одним из лучших экспертов по C#. И ни единой претензии к нему не было. Так что это ты в очередной раз соврал со вполне понятной целью — если даже ложки и найдутся, то осадок останется. ) Короче сливаться ты стал совсем банально.
_>>Да, и если разница в 1,5 раза — это убогий тормоз, то интересно как тогда ты охарактеризуешь результаты всех остальных языков по отношению к результату C++? I>Я в курсе, что ты тащишь С++ во все темы.
Так а почему бы его не притащить в тему про "замену js", если C++ сейчас (уже неделю как в двух основных браузерах и очень скоро в оставшихся двух) является вторым языком на котором можно писать код под браузер. Через некоторое время к нему добавится Rust, а потом думаю ещё и множество скриптовых языков, имеющих движки на C/C++ (т.е. практически все). Но на данный момент есть всего два языка, позволяющих писать прямо под браузер (компиляция неких языков в JS — это очевидно эрзац-технологии), так что в данном обсуждение C++ очень даже к месту. )))
Здравствуйте, Ikemefula, Вы писали:
_>>Ну приведи хоть один конкретный пример антипаттерна для Java, который при этом был бы характерен для написания C++ кода. Для обратной ситуации я легко могу привести подобный пример. I>Не смеши люди. Именно разница в дизайне и создаёт проблемы. С++ девелопер при попытке пересесть на джаву превращается в абсолютного новичка. Такому надо учиться использовать эффективно GC, встроеные кеши, интинсики и прочие тонкости. Числа сравнивать и то надо уметь I>http://www.odi.ch/prog/design/newbies.php#0
Ну так если превращается в абсолютного новичка, то это же как раз означает, что никак навыков из C++ ему в Java перетащить не удастся. Что напрямую противоречит твоему изначальному утверждению. )))
Здравствуйте, Serginio1, Вы писали:
V>>Ты заставляешь меня озвучивать банальности. Программа на скрипте отличается от программы на компиллируемом языке тем, что первая может хоть как-то исполняться даже будучи невалидной. Программа же на компиллируемом языке не сможет ничего исполнять, пока в ней будут ошибки компиляции. S>Я то пишу на ней.
Это засчитывается за аргумент?
Я тоже на 1C в разное время делал разные задачки, и?
Я хорошо понимаю, о чем речь.
V>>Они выигрывали раньше, потому что для компиллируемых не было поддержки IDE. V>>В отсутствии поддержки IDE рулил подход REPL, ОК. V>>В присутствии же нормальной IDE такой подход становится нелеп, архаичен, подлежит списанию в утиль. S> Угу. При этом питоном бользуется большая часть сишников.
Для малюсеньких утилитных задач, вместо еще более ограниченного bash или виндового cmd.
Легкость "написал-запустил" должна жить ровно там, где ей и положено — в несложной автоматизации рутинных операций.
Но тут же речь идёт о том, чтобы писать на скрипте большие системы.
А это уже очевиднейшая инженерная ошибка.
Причем, на 1C хотя бы из нейтива идёт ОЧЕНЬ много прикладного проблемно-ориентированного функционала, а на JS — аж нихрена, только базовые библиотеки. Весь проблемно-ориентированный код предлагается писать ручками.
А вот это уже ой.
V>>Программа-то целиком невалидна на скрипте, а ты и не знаешь. V>>Только по ошибкам в рантайме и видно. S> Конечно, я же 1С ник. И у меня ничего не работает
Да, периодически "конфигурации" 1C выдают ошибки именно у клиента.
Тоже мне новость.
V>>Я уже отвечал тебе, что до тех пор, пока такая аннотация опциональна, это всё равно, что её нет. S> То есть TS не нужен, Ты расписываешь про типизацию, но если она опциональна, то есть она и не нужна!!
Верно. Опциональная типизация не нужна.
Для сравнения в строго-типизированных языках "опциональная типизация" означает использование автовывода типов без вот этой "дыры" в смысле fallback до any. В TS содержится дыра.
S> При этом большая часть ошибок ловится на стадии даже не компиляции в отличие от С++, а на стадии проектирования. Ускоряется безошибочный ввод кода.
Опять бла-бла-бла.
Ты с кем тут споришь? Сам с собой? Оставить тебя наедине? ))
Не надо мне доказывать, что TS лучше, чем JS, бо я с этим и не спорил и вообще не собираюсь обсуждать в эту сторону.
Я вообще не вижу смысла обсуждать сорта ерунды.
Ладно бы взять TS для продолжения уже имеющегося проекта, тут вопрос "одно лучше другого" при сохранении обратной совместимости прокатывает, ОК.
Но когда кто-то говорит о НОВЫХ больших проектах на TS — сорри, это уже клиника.
Здравствуйте, alex_public, Вы писали:
I>>Судя по твоим предыдущим "тестам", от тебя ожидать можно всего угодно. Как то так.
_>Вообще то как раз именно этот тест подробно разбирался на форуме, в том числе и вместе с одним из лучших экспертов по C#. И ни единой претензии к нему не было. Так что это ты в очередной раз соврал со вполне понятной целью — если даже ложки и найдутся, то осадок останется. ) Короче сливаться ты стал совсем банально.
В твоем тексте никаких подробностей нет, кроме таблички. После твоих 'тестов' баз данных я тебе просто не верю.
_>>>Да, и если разница в 1,5 раза — это убогий тормоз, то интересно как тогда ты охарактеризуешь результаты всех остальных языков по отношению к результату C++? I>>Я в курсе, что ты тащишь С++ во все темы.
_>Так а почему бы его не притащить в тему про "замену js", если C++
Здравствуйте, alex_public, Вы писали:
_>>>Ну приведи хоть один конкретный пример антипаттерна для Java, который при этом был бы характерен для написания C++ кода. Для обратной ситуации я легко могу привести подобный пример. I>>Не смеши люди. Именно разница в дизайне и создаёт проблемы. С++ девелопер при попытке пересесть на джаву превращается в абсолютного новичка. Такому надо учиться использовать эффективно GC, встроеные кеши, интинсики и прочие тонкости. Числа сравнивать и то надо уметь I>>http://www.odi.ch/prog/design/newbies.php#0
_>Ну так если превращается в абсолютного новичка, то это же как раз означает, что никак навыков из C++ ему в Java перетащить не удастся. Что напрямую противоречит твоему изначальному утверждению. )))
Наоборот. Это в джаве он новичок. Соответственно, будет пытаться ехать на старом опыте. Например, я уже говорил, память он продолжает использовать как сиплюсник — пытается всё руками контролировать, но при этом не знает ничего про неявно создаваемые объекты и тд.
Типичный сиплюсник например вместо внятного ORM выберет какой нибудь jdbc просто потому, что опыта работы с ORM нет (чего ты сам продемонстрировал). С точки зрения С++ разработчика ОРМ это дико тормозная и абсолютно не нужная вещь.
Здравствуйте, gandjustas, Вы писали:
V>>Вот в очередь к этому контексту исполнения и копируются колбэки из других потоков. G>Каких "других потоков" ? Node нет "других потоков".
Здравствуйте, vdimas, Вы писали:
V>У коллеги получалось так, что колбэки от асинхронных операций приходили не в той последовательности, в какой инициировались.
Самое интересное, что ты отрицал существование этого эффекта и тебя пришлось три года к этом принуждать
vdimas>У нас бы довольно быстро read/write стали бы идти вперемешку. Но этого не происходит — строго 5 одних, потом 5 других, как они и были запущены изначально. JS работает как часы, браво!
Гляжу, скоро ты мою статью за свою выдавать будешь Я не против
