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

_C_>У меня блевательный рефлекс возникает как только заходит разговор об ООП. Большая часть программ сейчас — мелкие утилиты

Вы явно ошиблись выбором профессии. ЯП-ы тут не причём. Прикол, но другим (большинству) как раз в кайф и ООП, и новые ЯП-ы, и всё прочее.

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

J>>>·>А в чём принципиальная разница? Класс называется стеком, размещается в динамической памяти, и вместо вызова метода вызов метода возврата стека назад. Терминология изменилась, но судя по твоему описанию с т.з. CPU и RAM — всё то же самое.
J>>>Если совсем абстрактно говорить, в stackfull: стек — глоб переменная, в stackless: контекст явно протаскивается посредством Task/IEnumerable и прочее. Отсюда и все различия.
J>·>Глобальность переменных это абстракции про ЯП и удобство его использования с т.з. человеков. С т.з. железяки глобальные переменные ничем не отличаются от прочего. Так что я до сих пор не понял различия, ну кроме того разницы в названиях соответсвующих сущностей в реализации ЯП, опять же для человеков.

J>а с точки зрения желязки на контактах просто меняется напряжение и пофиг — пишешь ты на хаскеле или асме. Разговор ни о чем.
Разница как минимум в том сколько конретно контактов надо менять и как долго меняется напряжение.
Я хочу разобраться почему меня, как программиста на ЯП, должна волновать разница stackless/stackfull?
В обычной жизни когда я пишу программу, я знаю, что размещение данных на стеке более эффективно работает на железе, т.к. менеджемент памяти на порядки проще, не нужно никакой динамики, куч памяти, подсчётов ссылок, сборки мусора и прочего, тогда как классическая работа с классическим стеком это просто инкремент/декремент одного регистра. Это всё влияет на производительность и мои решения о выборе конкретного механизма.
А вот если идёт жонглирование фреймами стека и их перемещение туда-сюда, то стек становится не стеком, а чёрт знает чем, и я перестаю понимать разницу — какая разница чем ЯП там манипулирует вунутре и как оно там называется — фрейм стека или объект?

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

S>Если на проекте не выкобениваются и пишут тупо на Cи с классами, то C++ в на таком уровне тоже осилить за неделю не вопрос любой мартышке.

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

А в том, что на C++ всем приходится управлять вручную, в первую очередь -- управлять памятью. Что весьма не тривиально само по себе. И уж тем более в C++, где грабли можно встретить даже в элементарной std::min.

Именно поэтому был ряд экспериментов по созданию альтернатив C/C++ в нише низкоуровневого/системного программирования, но с безопасной работой с памятью. Успешным из которых, наверное, оказался только Rust. О простоте которого, в итоге, говорить не приходится.

На этом фоне Go невероятно простой язык с одним из самых низких порогов входа. Но при этом с хорошей производительностью, переносимостью и отсутствием "прицепа" в виде JVM или .NET-а. Шустрых и удобных нативных языков с GC пока не так много. Например, есть Eiffel и D. Но их освоить сложнее, чем Go, да и их популярность на фоне Go вообще никакая.

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

S>Это, мягко говоря, не так. И никогда так не было. И дело даже не в том, за какое время человек сможет осилить синтаксис языка и набор базовых понятий.

Это субъектвное мнение.

S>А в том, что на C++ всем приходится управлять вручную, в первую очередь -- управлять памятью. Что весьма не тривиально само по себе.

Это одна из саамых тривиальных вещей в программировании-выделил память, обеспечь её освобождение. Это в любом случае можно обеспечить, если тольо об этом не забыть. А вот в golang есть такая неприятная вещь как утечка подпрограмм, вот это, на мой взгляд, вещь более коварная и трудновылавливаемая и вообще неочевидная, чем утечка памяти в C/C++, но очень просто схватываемая, если только пишешь на golang что-то чуть более сложное, чем простая утилита. Есть и другие неприятности, причём в golang они все какие-то неочевидные и странные. Так что дефирамбы про отутствие трудностей в golang-это исключительно от того, что большинство ещё ничего сёрьёзного на нем не писало, по сложности сравнимого с тем, что писалось на С++. Так что не всё так очевидно просто.

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

S>>А в том, что на C++ всем приходится управлять вручную, в первую очередь -- управлять памятью. Что весьма не тривиально само по себе.

S>Это одна из саамых тривиальных вещей в программировании-выделил память, обеспечь её освобождение.

Простите, а вы вообще программист?

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

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

_C_>>У меня блевательный рефлекс возникает как только заходит разговор об ООП. Большая часть программ сейчас — мелкие утилиты

S>Вы явно ошиблись выбором профессии. ЯП-ы тут не причём. Прикол, но другим (большинству) как раз в кайф и ООП, и новые ЯП-ы, и всё прочее.
Так в том то и дело, что я не проф. программер, а всего лишь инженер, широкого профиля, и электронику на МК разрабатываю, и параллельные вычисления немного, и машинное обучение собираюсь.
Мы же говорим о массовости ЯП, так вот, массовый ЯП должен быть понятен сходу таким как я или студентам первашам. Им ваше ООП нах не нужно, чтоб написать первую программку. А дальше, когда освоят им другие ЯП лень осваивать, т.к. этот вполне устраивает своим удобством.

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

S>Простите, а вы вообще программист?

С 1999 по 2005 писал на Си и perl, в основном под SunOS. C 2005 пошли C++, python, c 2010 почти только С++ и python. В этом году в проект затащили golang. Всегда работал в разработке системного софта, демоны, утилиты, а также ядра linux и solaris. И повторю, управление памятью в C и C++ это одна из самых тривиальных вещей в программировании. Например, чуваки иногда славливали утечку памяти, в софте, написанном на ЯП-е с GC, вот это сложно, отлавливать утечку памяти в GC. Или сейчас появился golang с его гороутинами-вангую кучу проблем у чуваков с утечками ресурсов на проектах, сложнее примитивных утилит, и отлавливание этих утечек будет сложнее, чем управление памятью с C/C++.

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

S>И повторю, управление памятью в C и C++ это одна из самых тривиальных вещей в программировании.

Чего только на заборах в Интернетах не пишут...

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

S>Чего только на заборах в Интернетах не пишут...

Но для кого-то это сложно, да. Таких и golang, кстати, не спасёт.

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

S>Но для кого-то это сложно, да.

Есть мнение, что это сложно для всех, кроме вас.

S>Таких и golang, кстати, не спасёт.

Практика показывает, что стоит только пересадить человека с C++ на Java, C# или go, как написанный им код перестает жрать память и падает гораздо реже. И даже когда падает, то быстро становится понятно, где и из-за чего.

Но это субъективное мнение, основанное на субъективных же наблюдениях. Разве этому можно верить?

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

S>Есть мнение, что это сложно для всех, кроме вас.

Ну ok, любое мнение имеет право на существование.

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

·>Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться.
В том же Go — обычный (легковесный) стек без особой магии.

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

S>Для полей основного класса как правило передается сам объект, а не поля. Так, что не вижу в чем взрыв?
Представим, что у нас парсер SIP. Тогда естественно каждый уровень обработки сделать в своём классе отдельно и асинхронно. Получится что-то типа:

async Action* ParseSIPPacket(FrameSource f) {
   udpPacket = parseUdpPacket(f)
   // Parse SIP packet
...
}

async UDPPacket* ParseUDPPacket(FrameSource f) {
   ipPacket = parseIPPacket(f)
   // Parse UDP packet
...
}

async IPPacket* ParseIPPacket(FrameSource f) {
   ipPacket = parseEthPacket(f)
   // Parse IP packet
...
}

async EthPacket* ParseEthPacket(FrameSource f) {
    int packetLen = readPacketLen(f) //Might block
    char buf[packetLen];
    for(int i=0; i<packetLen; ++i) buf[i] = f.readByte(); //Might block

    return new EthPacket(buf);
}

Вот тут и начинаются варианты:
1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
2) Проходить все уровни вложения каждый раз при вызове асинхронной функции.

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

J>Нет. В том то и фича, что в stackfull варианте код выглядит как абсолютно синхронный, никаких тасков нету. Один минус, рантайм должен поддерживать подобную подмену стека.

Еще вопрос относительно потоков и stackful\stackless -- в обоих случаях работает один физический поток (корутины) или же в сл. stackless(stackful?) их будет больше одного?

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

C>Представим, что у нас парсер SIP. Тогда естественно каждый уровень обработки сделать в своём классе отдельно и асинхронно. Получится что-то типа:
C>

C>async Action* ParseSIPPacket(FrameSource f) {
C>   udpPacket = parseUdpPacket(f)
C>   // Parse SIP packet
C>...
C>}

C>async UDPPacket* ParseUDPPacket(FrameSource f) {
C>   ipPacket = parseIPPacket(f)
C>   // Parse UDP packet
C>...
C>}

C>async IPPacket* ParseIPPacket(FrameSource f) {
C>   ipPacket = parseEthPacket(f)
C>   // Parse IP packet
C>...
C>}

C>async EthPacket* ParseEthPacket(FrameSource f) {
C>    int packetLen = readPacketLen(f) //Might block
C>    char buf[packetLen];
C>    for(int i=0; i<packetLen; ++i) buf[i] = f.readByte(); //Might block

C>    return new EthPacket(buf);
C>}
C>

C>Вот тут и начинаются варианты:
C>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).

Почему должен быть взрыв?

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

C>>Вот тут и начинаются варианты:
C>>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
S>Почему должен быть взрыв?
Потому, что в одном методе должны быть скомбинированы все состояния из всех Parse-методов.

В данном примере это не так много, но легко представить случаи, когда оно может экспоненциально взорваться.

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

C>·>Как я понимаю, в stackful будет не обычный классический стек, а более сложная структура, в которой области локальных переменных нарезаны на отдельные куски и они могут туда-сюда подменяться и перемещаться.
C>В том же Go — обычный (легковесный) стек без особой магии.
И это там утечки подпрограмм, да?
Можешь объяснить детали на пальцах, что там такое? Ну или хотя бы ссылочку...

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

S>> Тебе так или иначе приходится возвращать код для динамичеких элементов, которые могут варьироваться от условий.

AK>За много лет — ни разу не приходилось.
AK>Если вы возвращаете какой-то JS-код из REST API-сервисов, то у вас что-то фундаментально не так с архитектурой.
Я не занимаюсь вэбом. Но часто приходится грабить сайты. И там многого насмотришься.
Но суть в том, что JS используется везде, в том числе и для получения динамических контролов со свои JS кодом для обработки событий.

S>>Другое дело SPA. Там тебе действительно не нужно знать JS.

AK>REST бэк-енду вообще все равно, что там на фронт-енде. Там может быть SPA, там может быть мобильное приложение, или какой-то другой сервис, который запросил эти данные.
AK>Если у вас бэкенд зависит от фронтенда, то вы на ровном месте нашли себе грабли.
Поэтому народ и идет в направлении SPA. Но он только начал этот путь. Поэтому всякие SMS с ПХП впереди планеты всей

AK>>>Я видел фронт-енд команды в нескольких компаниях. Они по количеству были не очень большими. Буквально, один синьор-тимлид и один-два джуниора.
S>> А по поводу "фронт-енд команды" смотрим на развитие Ангулара, и у меня большие сомнения в твоих утверждениях.

AK>А что с Angular такого специфического? Он вроде упрощает разработку, а не усложняет ее. Код на TypeScript хотя бы можно читать без поллитры.

Ангулар как раз это SPA. И действительно TypeScript во многих вещах даже поинтереснее C#.
Кстати если в опросах TypeScript занимает высокие место (20%) то на Tiobe он вообще отсутствует https://www.tiobe.com/tiobe-index/

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



C>Вот тут и начинаются варианты:
C>1) Все уровни вложения скомкать в один большой автомат (взрыв кода).
C>2) Проходить все уровни вложения каждый раз при вызове асинхронной функции.

Каждый метод это класс со своим автоматом.
Также сделано и для итераторов.
1. вариант это аналог инлайнинга, но не думаю, что для асинхронных вычислений это актуально.

yeld уже 13 лет. И они показали свою эффективнось

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

C>>В том же Go — обычный (легковесный) стек без особой магии.
·>И это там утечки подпрограмм, да?
Они возможны, но достаточно редкие.

·>Можешь объяснить детали на пальцах, что там такое? Ну или хотя бы ссылочку...
Каналы и сопроцессы.

Т.е. факториал будет:

// Создаём канал для вывода
var output = make(chan int64)

// "Запускаем" генератор
go func() {
   for i := 0; i < 10; i++ {
       output <- i // Возвращаем значение
   }
   close(output)
} ()

// В основном потоке читаем
for {
  val, ok := <- output
  if !ok {
     break
  }
  print(val)
}

Планировщик Go автоматически переключает лёгкие потоки, когда они блокируются (в этом примере при записи в канал).

Так как потоки реальные и имеют реальный стек, то они, в целом, получаются более дорогими, чем stackless coroutines. С другой стороны, если нужен реальный параллелизм (например, в сетевом сервисе), то они выигрывают.