Здравствуйте, Serginio1, Вы писали:

V>>Сам сижу на большом нейтивном проекте уже несколько лет и вижу, что его с каждым годом всё проще развивать, по мере накопления собственных библиотек. Потому что, повторюсь, в строго-типизированной среде не происходит "засорения" пространства имён, не происходит засорения перегруженных сигнатур ф-ий и т.д. А в JS можно убить любую ф-ию через создание одноимённой переменной. Или просто переопределить уже имеющуюся и знать никто не будет. ))
S>Ты TS каким языком считаешь?

Без перегрузки сигнатур ф-ий? ))
Костылём я его считаю.
Из разряда "на безрыбье сам раком встанешь".


S>Там та же модульность, пространства имен, та же типизация.

Типизация опциональна.
А значит, гарантий не даёт.
Это равносильно использованию типа object в Java и .Net, когда большой класс ошибок ловится только в рантайм.


S>C# кстати не является строго- типизированным. А те же динамики делают язык гибким без лишних оберток.

И опять ветер дует от того, что деревья качаются. ))
Эти dynamic нужны исключительно для вызова некоего нетипизированного скриптового АПИ.
Дай типизированное АПИ для скрипта+правила автоматического маршаллинга, и никакие dynamic будут не нужны.

Собсно Dart — это и есть компромиссный язык, где dynamic встроен изкаробки.
Ну вот такие сейчас пошли запросы — сопрягать скриптовый и компиллируемый код.
Понятное дело, что однажды это закончится тем, что скрипты станут резко отмирать.

Такое уже было на нашей памяти в ФП. Первые ФП-языки были интерпретируемые (речь не только о Лиспе).
Но сегодня мейнстрим ФП-языков — это компиллируемые языки.

Аналогично ООП.
Изначально ООП получил развитие в динамических-скриптовых языках.
Но сейчас уже де-факто мейнстрим ООП- компиллируемые языки.
С языками для веба подобный переходной процесс активно идёт последние лет 5.
Всё, хватит, наелись в вебе динамических языков.
Они тянут всю индустрию на дно.
При условиям современных реалий, где наличествует единый центр стандартизации веба, надобность динамических языков в вебе стала сильно под вопросом.


S> Ты кстати Dart расхваливал, а он ни чем не лучше TS. При этом тоже компилируется в JS.

В JS даже C++ компиллируется и?
Любой Тьюринг-полный язык можно скомпиллировать в другой Тьюринг полный, т.е. речь ни о чем.
Для Dart есть своя VM и есть планы предоставить возможность компиляции его в нейтив.
На сегодня так же есть тулчайны для Андроида, Линуха, Макоси, Виндов.

Т.е., сравнивать TS и Dart бессмысленно.
TS — это "снтаксический сахар" исключительно для скриптового окружения.
Dart — универсальный язык, пригодный как для веба, так и для эффективных клиентских приложений.
В вебе он умеет вызывать JS-код. В кач-ве компиллируемого языка программирования он умееть вызывать нейтивный код из библиотек.

Здравствуйте, alex_public, Вы писали:

I>>Питон по сравнению с JS убогий тормоз.

_>Это очередной миф, ... А вот если же взять JIT компилятор Питона (например PyPy), то сразу увидим, что разница в производительности колеблется в районе десятков процентов, что уже не принципиально для подобных языков.

Десятки процентов Это и есть убогий тормоз.

Здравствуйте, alex_public, Вы писали:

I>>Так с каждым языком. Если ты на Джаве начнешь писать как на плюсах, язык покажется очень кривым.

_>На Java невозможно писать как на C++, просто по определению. В силу дизайна языка.

Можно. Посмотри код сиплюсника когда он только-только на джаву пересел, это оно и есть. Первый год сиплюсник не код пишет, а только орёт, что язык говно. На второй уже успокаивается. На третий сам уже гнобит свежеиспеченного джависта-из-плюсов.

Здравствуйте, vdimas, Вы писали:



S>> Ты кстати Dart расхваливал, а он ни чем не лучше TS. При этом тоже компилируется в JS.

V>В JS даже C++ компиллируется и?
V>Любой Тьюринг-полный язык можно скомпиллировать в другой Тьюринг полный, т.е. речь ни о чем.
V>Для Dart есть своя VM и есть планы предоставить возможность компиляции его в нейтив.
V>На сегодня так же есть тулчайны для Андроида, Линуха, Макоси, Виндов.

V>Т.е., сравнивать TS и Dart бессмысленно.
V>TS — это "снтаксический сахар" исключительно для скриптового окружения.
V>Dart — универсальный язык, пригодный как для веба, так и для эффективных клиентских приложений.
V>В вебе он умеет вызывать JS-код. В кач-ве компиллируемого языка программирования он умееть вызывать нейтивный код из библиотек.

Еще раз TS может прекрасно компилироваться и в .Net IL. При этом уже не будет никакого сахара.
Кстати и C# компилируют в JS.
http://www.cshtml5.com/links/what-is-supported.aspx
https://metanit.com/sharp/articles/csharp/1.php

Он тоже стал синтаксическим сахаром?
Ты не поверишь. JS тоже умеет вызывать нативный код. Я тебе уже давал ссылку на CEF, а по WebAssembly рядом ветка.


По поводу перегрузки функций, то она есть
https://metanit.com/web/typescript/2.2.php


Но из за того, что JS не поддерживат перегрузку приходится делать так

function add(x: string, y: string): string;
function add(x: number, y: number): number;
function add(x: any, y: any): any {
    return x + y;
}

Или так

function getInfo(name: string): string;
function getInfo(age: number): string;
function getInfo(val: string|number): string {
 
    if (typeof val === "string")
        return "Имя = " + val;
    else if (typeof val === "number")
        return "Возраст = " + val;
    else
        return "undefined";
}

Насчет динамиков. Динамики нужны там, где заранее не известен тип. Но к нему можно сделать прокси.
Например вызов объектов и типов .Net Core из натива и JS через натив, вызов удаленных объектов по TCP/IP?
разбор часто меняющихся структур JSON, XML

Здравствуйте, novitk, Вы писали:

N>Внесу ложку дегтя.

N>Вeсь этот диснейленд, который ты описал в wasm, был много лет назад уже проделан с Явой, но оно не взлетело. Чисто с практической точки зрения, wasm по сравнению с JVM хуже всем (sandboxing, payload size, tooling, libs), кроме возможно скорости. Однако смотря на Minecraft, сдается мне, что скорость для всего, что вообще имеет смысл запустить в браузера с песочницей, может быть вполне себе приемлема.

В джаве много чего не взлетело и что с того ? В браузер пытались встроить чуть не всё подряд — кучу языков, несколько разных VM, кучу полу-стандартов. Из этого следует, что спрос есть. Фактически, все применение для этой кунсткамеры это вычисления и обработка данных. Все эти решения были одинаково кривыми.

N>ИМХО, вопрос интеграции с объектами браузера абсолютно ключевой. Программировать клиентов на C++ мало кто будет, то есть для реальной смерти JS нужно еще перенести туда как минимум что-то легкое типа Питона/Руби и прокинуть в него DOM-байндинги. Это не говоря о Яве и .NET. Это все годы, если не пятилетки работы.

Байндинги прокидывать достаточно легко. Речь не только про интеграцию с объектами браузера. Нужно общее решения и для секурити, и для общего хипа и тд и тд. Фактически, wasm дает делает браузер полноценной платформой. Здесь, правда, мешает Сафари — в ём всё очень особенное. Т.е. платформа изначально получается раздробленая.

Здравствуйте, alex_public, Вы писали:

G>>Как по мне managed-язык это тот в котором временем жизни объектов управляет "среда". Это может быть отдельный "рантайм" в виде GC, а могут быть и правила компилятора, которые в нужные места втыкают вызовы. Самое главное что это происходит неявно для программиста, снимая с программиста заботу об этом.

_>Правильно ли я понимаю, что если я напишу на C++ программу, в которой не будет ни одного явного new/delete, то это будет означать, что программа написана на управляемом языке? )

На двух языках(А и Б) можно написать программы, которые будут идентичны друг другу вплоть до байтов и битов. Значит ли это что язык А принадлежит семейству Б или наоборот ?
Пример такой программы:

print "hello world"

Следует ли из этого, что питон статически типизируемым ?

А если так

"hello world"

Следует ли из этого, что повершел стал декларативным языком или функциональным ?

А если так

hello world

Следует ли из этого, что HTML стал, ужос, императивным языком ?

Домашнее задание — найти для каждого примера второй язык из указаного семейства.

Здравствуйте, vdimas, Вы писали:

V>Я дал тебе вполне конкретную ссылку на юмор.
V>Там в конце есть ссылка на "статью" от коллеги.
V>Сама статья была написана коллегой из-за непонимания принципов работы node.js.
V>Знаний об "однопоточности" мало в асинхронном фреймворке.
V>Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.

Статья, что характерно, демонстрирует описаную тобой проблему. Фактически, это домашнее задание студентам, найти ошибку.
Ты, кстати, определись, реактор там или проактор. А то год прошел, у тебя новые показания

V>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.

Ну теперь то ты сможешь объяснить, почему последовательность выполнения недетерминирована и откуда берутся гонки ?

Здравствуйте, gandjustas, Вы писали:

V>>Каждая асинхронная операция имеет возможность завершится конкурентно с другой, если реактор у нас работает, например, на пуле потоков поверх IOCP. Поэтому, прежде чем делать что-то асинхронно, в первую очередь необходимо выяснить потоковую модель такой асинхронности.
G>Завершаться может когда угодно, а коллбеки в JS вызываются строго последовательно. Если же ты попробуешь иницииоровать две асинхронные операции с одним ресурсом в одно время, о получишь или ошибку или одна выполнится после другой. Так что состояние гонки в js ты не получишь никаким образом.

Господи, "одна выполнится после другой" и дает те самые гонки, поскольку порядок выполнения недетерминирован.

V>>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
G>Нет. Никакой ввод-вывод в других потоках не исполняется. Есть один поток выполнения, все хендлы принадлежат ему, весь ввод вывод инициируется в нем, все коллбеки выполняются тоже в нем.

Весь ввод-вывод выполняется в других потоках. JS-поток только шедулит вызов и принимает результат чз эвентлуп.

Вы ребята похоже один другого стоите.

Здравствуйте, vdimas, Вы писали:

V>Дело не в названии, а в гарантиях.
V>node.js помимо всего прочего, что операции ввода-вывода для каждого отдельного файлового хендла будут привязаны к одному и тому же потоку.
V>Тут на сайте был разбор примеров, где это имело значение (разбирал я с Ikemefula). Т.е., человек работает с языком, а что там на самом деле происходит — понятия не имеет.

Цитирую некоего vdimas

Так вот, м/у read и его колбеком не происходит НИЧЕГО

V>В итоге мне надоели эти бодания:
V>http://www.rsdn.org/forum/humour/6444719.1
V>))

Раз уж меня упомянули, то я дам ссылку на финальную часть, http://rsdn.org/forum/flame.comp/6454141.1

Автор: Ikemefula
Дата: 26.05.16

--------------------------------------------------------------------------------------------------

V>Если бы вот это было верно:
V>
I>>между read и его колбеком проходит время и здесь может отработать сколько угодно других функций.
V>
V>У нас бы довольно быстро read/write стали бы идти вперемешку. Но этого не происходит — строго 5 одних, потом 5 других, как они и были запущены изначально. JS работает как часы, браво!

Надеюсь, ты не не возражаешь и я добавлю в твой пример немного логирования ? пронумеровать вызовы read/write, что бы посмотреть что же в промежутке между read и его callback

	вариант vdimas + моё логирование
	'use strict'; const Buffer = require('buffer').Buffer; const fs = require('fs'); var fd = fs.openSync('i', 'w+'); var i = 0; var readCursor = 0; var writeCursor = 0; var kr = 0; var kw = 0; function read_i(clb) { var buffer = new Buffer([0]); var k = ++kr; console.log('read', k); fs.read(fd, buffer, 0, 1, readCursor++, (err, bytesRead, data) => { console.log('read callback', k); if(err) { console.log('Error on read: ' + err.toString()); return; } clb(data.toString()); }); } function write_i(i, clb) { var k = ++kw; console.log('write', k); fs.write(fd, i%10, writeCursor++, (err, written, data) => { console.log('write callback', k); if(err) { console.log('Error on write: ' + err.toString()); return; } clb(data); }); } function writeTask() { if(i >= 100) return; var localCopyOf_i = i++; write_i(localCopyOf_i, data => { //console.log('write', data, '(' + localCopyOf_i + ')'); readTask(); }); } function readTask() { read_i(data => { //console.log('read ', data); writeTask(); }); } for(var j = 0; j < 5; j++) writeTask();

И вот порка твоего 'решения':

read 26 <-----  
write callback 27
read 27
write callback 28
read 28
write callback 29
read 29
write callback 30
read 30
read callback 26 <-----
write 31
read callback 27
write 32
read callback 28
write 33
read callback 29
write 34
read callback 30

'read/write стали бы идти вперемешку' @ vdimas — как видишь, они именно так и идут — вперемешку.

Здравствуйте, Ikemefula, Вы писали:



I> Весь ввод-вывод выполняется в других потоках. JS-поток только шедулит вызов и принимает результат чз эвентлуп.

I>Вы ребята похоже один другого стоите.

Кстати про потоки и зоны
Angular 2 EventEmitter событие вызывается, но данные не обновляются

Хорошая статья
Что такое Зоны(Zones)?

Здравствуйте, Serginio1, Вы писали:

I>> Весь ввод-вывод выполняется в других потоках. JS-поток только шедулит вызов и принимает результат чз эвентлуп.

I>>Вы ребята похоже один другого стоите.

S> Кстати про потоки и зоны

Ребята пока путают реактор с проактором. Как разберутся, тогда можно и зоны смотреть.

del

Здравствуйте, gandjustas, Вы писали:

G>не ту ссылку скопировал. вот правильная https://habrahabr.ru/post/202304/

Это не эксель. Это примитивная электронная таблица.

Здравствуйте, Ikemefula, Вы писали:

I>Цитирую некоего vdimas
I>

I>Так вот, м/у read и его колбеком не происходит НИЧЕГО

Я там же следом для особо понятливых и пояснил — м/у операцией read и её колбэком.
Мне показалось, что ты тогда понял. ))

Потому что это ж азы работы с многопоточностью: если у тебя нет явных ср-в синхронизации потоков, то ты не можешь делать никаких предположений относительно того, в какой точке исполнения находится каждый поток.


I>Надеюсь, ты не не возражаешь и я добавлю в твой пример немного логирования ? пронумеровать вызовы read/write, что бы посмотреть что же в промежутке между read и его callback

На новый круг, что ле?
Ты ДЕЙСТВИТЕЛЬНО не понимаешь, что вызовы read в твоём коде не производит собсно чтения?

Я тебе там же более одного раза пояснил, что ты не можешь знать, происходит ли что-то или нет м/у самой операцией чтения и колбэком, т.е. ты можешь считать, что не происходит ничего. Потому что, у тебя физически нет способа это как-то проверить в коде JS.


I>И вот порка твоего 'решения':

Ох...
Получается так, что ты до сих пор считаешь, что если ты вывел в лог некий текст "read 26", то у тебя действительно происходит чтение?
Ну вот ты вывел этот текст в лог и JS должен делать то, что ты "приказал" ему через запись в лог???
а-а-а-а-а-а-а-а

Я сдаюсь... Ты безнадёжен. ))

Здравствуйте, Ikemefula, Вы писали:

I>Статья, что характерно, демонстрирует описаную тобой проблему.

Статья демонстрирует непонимание тобой гарантий, даваемых каждой из моделей асинхронного IO.

А я лишь настаиваю на том, что необходимо предварительно выяснять асинхронную потоковую модель, и только потом что-то поверх неё делать.
Выяснять не для удовлетворения сугубо любопытства ради любопытства, ес-но, а чтобы оперировать в разработке знаниями о предоставляемых гарантиях, присущих каждой конкретной модели асинхронного IO.

Вам ведь не самую кучерявую модель дали, кста. А могли. ))
Похоже, решили не рисковать, хорошо понимая, каков будет средний контингент разрабочиков на ноде.


I>Фактически, это домашнее задание студентам, найти ошибку.

И что ж ты сам не нашел?


I>Ты, кстати, определись, реактор там или проактор. А то год прошел, у тебя новые показания

Показания всё те же:
1. Рядом

С>Поскольку Нода делалась в первую очередь под линуксы, то и и модель там — реактор, т.к. ниже лежат poll, epoll.
Садись, два. ))
Из низлежащего реактора можно сделать проактор.

2.Было сказано "если".

Очевидно, что ты не в курсе того, что IOCP может работать и в режиме реактора — тут достаточно начинать асинхронную операцию с аргументом WSABUF, у которого указана нулевая длина буфера. Тогда мы получим модель асинхронщины аккурат как в линуховом epoll — т.е. будем получать лишь оповещения о готовности IO.

Сорри, конечно, но я не всегда принимаю в расчёт уровень эрудиции каждого из потенциальных читателей. И никто не ориентируется на "всех". Это нормально. Если что-то показалось непонятным — тут надо банально спросить, а не пытаться в чём-то обвинять.
Потому что спросить — не зазорно.
Но обвинить кого-то в чем-то и оказаться потом неправым — это уже ой, это уже залёт.


V>>В одном потоке в node.js только твой JS-код выполняется, а сам-то node.js многопоточный, у него вся работа по вводу-выводу выполняется в других потоках.
I>Ну теперь то ты сможешь объяснить, почему последовательность выполнения недетерминирована и откуда берутся гонки ?

Ну, у меня-то всё строго детерминировано — я показал как этого достичь и подробнейшим образом объяснил происходящее. Там должен быть понять даже студент.

Здравствуйте, vdimas, Вы писали:



V>Я тебе там же более одного раза пояснил, что ты не можешь знать, происходит ли что-то или нет м/у самой операцией чтения и колбэком, т.е. ты можешь считать, что не происходит ничего. Потому что, у тебя физически нет способа это как-то проверить в коде JS.

Что такое Promise?

Promise – это специальный объект, который содержит своё состояние. Вначале pending («ожидание»), затем – одно из: fulfilled («выполнено успешно») или rejected («выполнено с ошибкой»).

TypeScript 2.1: async/await for ES3/ES5

function delay(ms) {
    return new Promise(function (resolve) {
        setTimeout(resolve, ms);
    });
}
async function asyncAwait() {
    console.log("Knock, knock!");
    await delay(1000);
    console.log("Who's there?");
    await delay(1000);
    console.log("async/await!");
}

Здравствуйте, gandjustas, Вы писали:

_>>Правильно ли я понимаю, что если я напишу на C++ программу, в которой не будет ни одного явного new/delete, то это будет означать, что программа написана на управляемом языке? )
G>Нет. Ты явно будешь использовать умные указатели или аналогичные классы, управляющие ресурсами. Если ты вдруг не используешь эти классы, то получится утечка.

Всё верно. Но мы же можем просто запретить использовать явные new/delete в проекте. Причём это можно сделать не только административно, но и технически (через статический анализатор).

G>Еще раз managed это когда "среда" дает тебе гарантии, а не программист что-то делает, чтобы утечек не было.

В случае современного C++ программисту не надо ничего делать, чтобы не было утечек. Ему скорее не надо делать определённые опасные операции.

И да, это не значит, что я считаю C++ управляемым языком. ))) Однако если исходить из твоих взглядов на Switf, то C++ тогда тоже управляемый. )))

Здравствуйте, Serginio1, Вы писали:

S> Еще раз TS может прекрасно компилироваться и в .Net IL.

Этого мало, надо уметь оперировать возможностями платформы.
Сможешь ли ты вызвать .Net Interop из TS?


S>Кстати и C# компилируют в JS.
S>Он тоже стал синтаксическим сахаром?

Я уже отвечал на это:

Я че-то проблематики не улавливаю при переводе из более сильной системы типов в более слабую.
А в бинарник нейтива как программы переводятся? Там же вообще типы затираются.

S>JS тоже умеет вызывать нативный код.

Не умеет.
Посмотри исходники либ для ноды — что там делается, чтобы этот код стало возможным вызывать из JS.


S> По поводу перегрузки функций, то она есть
S>https://metanit.com/web/typescript/2.2.php

Это не перегрузка, это динамика.


S>Но из за того, что JS не поддерживат перегрузку приходится делать так
S>Или так
...

Во-во.
Сам же всё видишь, но споришь ради спора, что ле?


S>Насчет динамиков. Динамики нужны там, где заранее не известен тип.

Я и на это уже отвечал:

Эти dynamic нужны исключительно для вызова некоего нетипизированного скриптового АПИ.
Дай типизированное АПИ для скрипта+правила автоматического маршаллинга, и никакие dynamic будут не нужны.

Потому что не может быть "неизвестен тип" в нормальном АПИ.
Вот весь тот пост, там развёрнуто:
http://www.rsdn.org/forum/flame.comp/6731499.1


S>Но к нему можно сделать прокси.
S>Например вызов объектов и типов .Net Core из натива и JS через натив, вызов удаленных объектов по TCP/IP?
S>разбор часто меняющихся структур JSON, XML

"Частоменяющиеся" — не при чем, у тебя в любом случае код должен уметь работать с той версией, про которую знает. Так вот, эти "знания" вполне себе поддаются типизации.

Про вызов удалённых процедур — аналогично. Первые два десятилетия существования подобных технологий как таковых сами удалённые процедуры вызывались строго типизированным образом через предварительно описанный IDL.

Здравствуйте, Ikemefula, Вы писали:

_>>Это очередной миф, ... А вот если же взять JIT компилятор Питона (например PyPy), то сразу увидим, что разница в производительности колеблется в районе десятков процентов, что уже не принципиально для подобных языков.
I>Десятки процентов Это и есть убогий тормоз.

Всё относительно. ) Вот если мы возьмём например этот http://rsdn.org/forum/flame.comp/6729734.1

Автор: alex_public
Дата: 20.03.17

тест, то PyPy выдаёт в нём 24,8 мс, что в 1,6 раза хуже результата JS. В том же тесте C# выдаёт в точности такую же разницу по отношению к Java. Означает ли это, что можно сказать, что C# — это убогий тормоз по сравнению с Java? )))

Да, и если разница в 1,5 раза — это убогий тормоз, то интересно как тогда ты охарактеризуешь результаты всех остальных языков по отношению к результату C++?

Здравствуйте, Serginio1, Вы писали:

Зря ты влез в этот спор. ))
Там у нас просходит бодание сугубо по интерпретации моей фразы "операция read".

Я её интерпретирую так, что речь идёт о действительном чтении, а коллега Ikemefula усиленно делает вид, что имелся ввиду момент исполнение строки read(args) в исходнике JS, где во время исполнения этой строки никакого чтения не происходит ес-но, бо прямо в документации node.js сказано, что происходит лишь инициализация асинхронной операции.

Всё остальное в том споре — это продолжение давнего обмена любезностями и попыток Ikemefula хоть что-то хоть кому-то доказать.