LINUX.ORG.RU

Почему Go это плохо, и он вам, на самом деле, не нужен.

 ,


7

15

Давайте я вам поясню про язык Go, откуда у него растут корни, и почему его на самом деле не стоит использовать. То что напишу ниже, это взято как из инсайдерской информации, так и из материалов, доступных в интернетах.

Дело в том, что Go это, на самом деле, «решение» внутренних гугловских проблем. Но отнюдь не проблем горизонтального масштабирования серверного ПО, как многие почему-то думают. Он приспособлен специально для использования в гугле вот в каком контексте.

Гугл нанимает большое количество тупых студентов, только-только после вуза или ПТУ, и заставлять их писать хоть какой-то простой код. И делать минимум ошибок, при этом. Для этого Go сделан таким тупым и упрощенным. И выкинут в паблик он только для того, чтобы вероятность, что у такого студента, только пришедшего в гугл, было хоть какое-то знание Go, была выше нуля.

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

Из гугла же идет маразматическая система управления зависимостями Го, которая заточена на монорепы.

Тут возникает вопрос - а почему этому тимлиду не дать в руки кодогенератор, вместо всей этой accidental complexity, возникающей из-за огромного количества строк кода, и из-за затрат на коммуникацию?

А тут надо понимать, как внутри устроены огромные корпорации типа гугла.

Их давно пожрал рак бюрократии. Там у менеджерских и околоменеджерских должностей один из главных критериев промоушнов, или вообще даже ассесмента(усидения на должности), это количество людей у тебя в подчинении. И количество говнокода в вакууме которая твоя команда написала. И вот все эти люди, сидящие на более-менее средне-высоких должностях, постоянно бодаются за эти промоушны и ассесменты. Это их главная и единственная цель. Поэтому, ни о какой эффективности тут речи не идет вообще от слова совсем. Тут главное - корпоративные игры, количество голов в твоем стаде и количество и размер высеров, которые это твое стадо произвело(причем буквально, важны SLOC).

Естественно, это все отражается на качестве продуктов, и это видно как по полному прекращению инноваций в гугле, так и по постоянно мелькающим и закрывающимся высерам этой компании - hangouts, duo, google plus, google wave, и прочее и прочее, можете еще вспомнить много чего.

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

Никакой мифической простоты в отладке и в понимании кода Go не приносит. Да и сложность программных систем растет совершенно не из-за понятности/непонятности какой-то отдельной взятой строчки кода или функции. Потому, что, во-первых, понятность это понятие субъективное, во-вторых потому, что, отдельно взятая фунцкия на 5 строк понятна любому опытному программисту, будь она написана хоть на Rust, хоть на Common Lisp.

Сложность программных систем возникает из-за их размера. И Go эту проблему значительно ухудшает. Человек не может удерживать в голове слишком много вещей, даже если каждая отдельная вещь - очень простая. Количество RAM в голове ограничено.

В случае если вы не хотите выкидывать кучу денег просто так, и скорее предпочли бы нанять немного, но более-менее опытных программистов, Go будет только вреден, потому что все вменяемые люди от него, на самом деле, плюются. Он реально отталкивает опытных людей, которые способны понять сложные требования и написать, и поддерживать, более-менее сложные системы уровнем хотя бы нескольких сервисов плюс БД и MQ.

★★
Ответ на: комментарий от lovesan

indirect ссылками(начиная с Pimpl или там std::vector)

У вас даже std::vector затормозил? O_o, O_o, O_o! Это нужно было суметь.

eao197 ★★★★★
()
Ответ на: комментарий от lovesan

даже индирект не нужен, джуны смогли: 4-5 вложенных циклов где на каждый чих пробегаются все записи в таблице данных…

necromant ★★
()
Ответ на: комментарий от lovesan

Это просто внешняя функция от двух аргументов. Типы аргументов: Foo* и std::string

Медленнофикс - const char* конечно там тип второго аргумента

lovesan ★★
() автор топика
Ответ на: комментарий от necromant

джуны смогли: 4-5 вложенных циклов где на каждый чих пробегаются все записи в таблице данных…

Уже есть какой-то язык программирования, который от таких вещей защищает?

eao197 ★★★★★
()
Ответ на: комментарий от lovesan

И натравим на полученный объектник nm, то мы найдем там символ _ZN3Foo5HelloEPKc

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

alysnix ★★★
()
Ответ на: комментарий от lovesan

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

alysnix ★★★
()
Ответ на: комментарий от lovesan

В CLOS никакого «duck typing»

Заметь, я не сказал «CLOS», я сказал «лиспы» %)

Хотя да, тут я неправ был — лиспы могут поддерживать и номинальную, и структурную типизацию (и обе разом), в отличие от других недоязычков.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от unsigned

Мне вот довольно очевидно, что от ООП в плюсах куцый огрызок. ООП всё про про построение динамических объектных систем. Построение это требует рантайм-рефлексии и метаобъектного протокола.

в критикуемом посте, я вообще-то говорил не про ооп, а про «абстрактный тип данных». я про наследование например ни слова не сказал.

я вот сказал, что класс в ооп, это абстрактный тип данных(если это интерфейс) и реализация абстрактного типа данных, если это класс, и он должен быть определен локально и полно, а не размазываться по всему коду.

«абстрактные типы», что динамически меняют свои свойства…это уже не абстрактные типы, а какая-то иная парадигма динамических сущностей, семантика которых не ясна.

если вы из типа «мышка» можете динамически сделать тип «автомобиль», и мышки у вас едят кошек, то это точно не абстрактные типы, а ужас в стиле босха.

alysnix ★★★
()
Ответ на: комментарий от alysnix

в лиспе «видимость» есть у символов, и не относится к ООП.

Символы группируются в пакеты(неймспейсы грубо говоря). Не экспортируешь какой-то символ - значит он не является частью публичного интерфейса. Всё.

(defpackage #:mypkg
  (:use #:common-lisp)
  (:export #:foo
           #:foo-value))

(in-package #:mypkg)

(defclass foo ()
  ((value :accessor %foo-value
          :reader foo-value)))

Здесь символ %foo-value - внутренний символ в пакете, значит пакет не предоставляет интерфейса изменения значения поля value

lovesan ★★
() автор топика
Ответ на: комментарий от unsigned

Построение это требует рантайм-рефлексии и метаобъектного протокола.

Вот прям так и требует?

thesis ★★★★★
()
Ответ на: комментарий от thesis

в жабе и дуднете любой +- крупный проект обмазан рефлекшном, и даже кодогенерацией в рантайме, по самые уши - тут и конфиги, и сериализация, и Dependency Injection, и все остальное, типа проксей к таблицам в ORM

Так что да

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Про то как делается UI я вообще даже помолчу - там рефлекшн на рефлекшне и рефлекшном погоняет, как пример WPF и Avalonia - там по сути статическая типизация как корове пятая нога, там повсюду Object, и в итоге получается очередное «кривое и глючное переизобретение половины Common Lisp»(включая интерпретаторы XML)

Но надо сказать что C# том же, это выглядит еще более-менее удобноваримо, в отличие от сракотана который представляет из себя Qt.

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

в лиспе «видимость» есть у символов, и не относится к ООП.

вот абстракция на плюсах

class A {
  void ff();
public :
  void f();
}

тут видно, что ff можно вызвать только из f; а f - откуда угодно от обьекта класса A.

как эти ограничения видимости методов записать в лиспе?

alysnix ★★★
()
Ответ на: комментарий от lovesan

Про то как делается UI я вообще даже помолчу - там рефлекшн на рефлекшне и рефлекшном погоняет

UI в wxWidgets делается безо всяких рефлексий. просто там он делается нормальными людьми.

alysnix ★★★
()
Ответ на: комментарий от alysnix

UI в wxWidgets делается безо всяких рефлексий. просто там он делается нормальными людьми.

На такие аргументы всегда найдется возражение, что UI на wxWidgets – это днищенское дно.

eao197 ★★★★★
()
Ответ на: комментарий от alysnix

У тебя «класс» тут всего лишь реализует неймспейс, вот и всё. Выше я уже написал про пакеты.

Но конкретно этот случай, для одиночной диспетчеризации, можно сделать довольно легко, для совсем упоротых по public/private хероте которая ничего на самом деле не гарантирует.

(defgeneric private-method (object)
  (:method :around (object)
    (declare (special *caller*))
    (unless (and (boundp '*caller*)
                 (eq *caller* object))
      (error "Private context violation"))
    (call-next-method)))

(defgeneric public-method (object)
  (:method :around (object)
    (let ((*caller* object))
      (declare (special *caller*))
      (call-next-method))))

Далее определяем свой класс методы к нему:

(defclass foo ()
  ())

(defmethod private-method ((object foo))
  (write-line "Private method"))

(defmethod public-method ((object foo))
  (write-line "Public method")
  (private-method object))

В случае вызова извне, private-method вызовет ошибку, в случае вызова из public-method - отработает нормально

Далее это можно абстрагировать через метаобъектный протокол и макросы, для общего случая.

Но никто так не делает, потому что это нахрен никому не сдалось.

Потому что проблемы видимости решаются пакетами, это раз, а два - потому что сама идея public/private/protected (в C# есть еще protected internal, а в самом .NET еще есть FamAndAssem) - нужна как раз только и исключительно для того чтобы определить внешний интерфейс класса, а не для того чтобы «нельзя вызвать» было (потому что в .NET и JVM вызывать через рефлекшн все-равно в любом случае можно).

lovesan ★★
() автор топика
Ответ на: комментарий от eao197

на любое высказывание всегда найдется испепеляющее возражение. это вообще не относится к IT, а к риторике, как дисциплине.

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

alysnix ★★★
()
Ответ на: комментарий от eao197

Впервые солидарен вот с этим пассажиром

wxWidgets это просто уровень дно пробито, привет 90е, и так далее

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

В случае вызова извне, private-method вызовет ошибку, в случае вызова из public-method - отработает нормально

у тебя динамическая проверка, в которую каждый сможет, такую же функциональность можно на си написать. а ты статическую напиши.

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

а в статической проверке ты проверяешь просто вызвав компилятор.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

Короче, ой всё, я старался, но у пассажира видимо мозг сломан крестами, и он слишком уж зашорен.

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

wxWidgets это просто уровень дно пробито, привет 90е, и так далее

и что такого передового надо иметь, чтобы написать либу графических виджетов??? графические виджеты это просто набор примитивных классов, рисующих рамки, фоны, дочерние элементы и умеющие сигналить по реакции от юзера. там больше и не надо ничего.

alysnix ★★★
()
Ответ на: комментарий от lovesan

wxWidgets это просто уровень дно пробито, привет 90е, и так далее

Пример хорошего современного UI можете привести?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Qt приемлим, но плюсы. winforms были неплохи лет пятнадцать назад, но прибиты гвоздями к winapi. Про wpf и дальнейшее сказать особо нечего, как и про avalonia.

Про tk в связке с python впечатления остались неоднозначные.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Не, это все инструменты.

Интересны примеры приложений, в которых, типа хороший современный UI.

Как по мне, то как раз в 90-е на Win и OS/2 как раз таки делали GUI приложения для людей (и, вообще-то говоря, мало кого парили формы кнопочек с псевдо-3d-эффектами).

А вот, скажем, современный MS Word, в плане UI для меня как раз дно днищенское. Или Settings в Chrome. Вот это вряд ли (с моей точки зрения) можно назвать удобным UI. Но, вроде как, современный.

eao197 ★★★★★
()
Ответ на: комментарий от lovesan

ООП это как раз про динамическую диспетчеризацию

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

eao197 ★★★★★
()
Ответ на: комментарий от eao197

WPF обогнал свое время примерно на десятилетие(а то и пару), когда появился. То же самое с Silverlight - кто на нем писал, помнит, насколько это было удобно по сравнению с современным сракотаном, творящимся в вебе и электроне. Avalonia - кроссплатформенный вариант.

На основе WPF, с теми же принципами(XAML итд), появились Xamarin.Forms, ну и потом у MS щас есть всякие MAUI и WinRT/UWP/WinUI. Но дефолт под винду это все еще WPF.

Андроидовское дефолтное UI кстати, отчасти, сделано по этим же принципам, можно сказать во многом слизано. iOS особо не трогал, но говорят там похоже на андроид, только гораздо менее удобно и в целом всрато(впрочем разработчики под яблоговно это по определению анальные садомазохисты).

У жабы на десктопе все довольно всратенько, лучшее что есть это JavaFX, но она тоже довольно всратая, не осилили как WPF сделать нормально. У JetBrains вроде какой-то внутренний фреймворк, который сделан путем сильно пересобаченного SWIG, но честно говоря, интерфейсы у их продуктов довольно всратенькие по сравнению с той же MSVS которая на WPF, так что не думаю что там что-то далеко ушедшее от SWIG.

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

Всякие GTK, wxWidgets, и так далее - это говно мамонта из прошлого тысячелетия вообще(что там еще? WTL? FLTK? Tk? вот это вот все - говно мамонта).

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Это все внутренняя кухня, которая касается программиста.

Интересны примеры приложений, которые обладают хорошим UI, а не дном днищенским.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

Idea более-менее норм, но там текстовый редактор, современность там только в отсутствие кучи панелек с кнопками по-дефолту. vscode вроде более-менее.

А так всё остальное что использую имеет интерфейс концептуально из конца 90-х.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

А вот сложно, да.

Ну вот о том и речь :(

ИМХО, конкретный фреймворк здесь не то, что вторичен, он даже третичен. На первый план выходит желание и возможность сделать удобно для пользователя и заточенно под задачу. Чтобы работать, а не рюшечки.

И вот с этим проблем больше, чем с Qt/wsWidgets/FOX/FLTK/ImGui и пр.

PS. В свое время был удивлен тому, как Dear ImGUI был востребован в определенных нишах и как (и сколько) на нем педалят специализированного софта для специфических нужд и никого не парит внешний вид получающихся наколеночных поделий.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Пример приложения со сложным, но при этом удобным, качественно сделанным, отзывчивым и кастомизируемым современным UI это та же Visual Studio последних версий.

Плюс, у Avalonia есть showcases

https://avaloniaui.net/Showcase

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

вообще не понял, что нужно иметь в языке, чтобы сделать продвинутый гуй. рефлексии? динамическое связывание? интерпретируемый язык? что за ерунда, вашу мать.

с++ 100 процентно ложится на разработку либы для гуя, даже дельфи отлично ложилось в свое время.

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

alysnix ★★★
()
Ответ на: комментарий от lovesan

это та же Visual Studio последних версий.

Плюс, у Avalonia есть showcases

От каких-нибудь CorelDRAW или MS Word 6.0 из середины 1990-х отличается разве что оформлением контролов. Тогда упарывались под 3D, сейчас все упарываются под «плоские контролы».

eao197 ★★★★★
()
Ответ на: комментарий от lovesan

есть ощущение, что все эти «качественно сделанные» отличаются лишь тем, что у фирмы есть бабло, чтобы усадить людей, что отрисуют любой стандартный контрол красивым кастомным образом с помощью дизайнера.

в wхwidgets тоже можно кастомно рисовать стандартные контролы. ну и свои городить.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от eao197

В плюсах мешает нехватка механизмов для простых, рутинных задач. Я их упомянул.

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

Имхо, для объектной системы это пример базовых кирпичей. Если их нет и нельзя сделать в библиотеке, то да, это мешает. Не в смысле «делает невозможным», а в смысле - забивает голову и кодовую базу низкоуровневой фигней. Как если бы для вызова функции приходилось каждый раз расписывать «push, push, call». Это и значит: язык не поддерживает концепцию.

Статичная типизация тут немного побоку, хотя понятно что она ограничивает динамичность, и самые ООП-шные языки - динамические.

unsigned ★★★★
()
Ответ на: комментарий от unsigned

В плюсах мешает нехватка механизмов для простых, рутинных задач. Я их упомянул.

Простите, мне не хватило предыдущего описания. Поэтому и был задан вопрос.

Например, выхватить произвольный объект, разобрать на части, передать куда-то, пересобрать.

Зачем? Если это нужно для IPC или для сохранения на диске в виде файла, то существуют различные системы сериализации/десериализации, заточенные под разные нужды. И да, действительно серьезные вещи требуют специализированного языка описания (в том или ином виде) из которого кодогенерацией получается оптимизированный код.

При чем здесь ООП не очень понятно. Разве что хочется влезть в потроха чужого объекта и поправить там что-то ручками. Что вообще-то посылает вдоль инкапсуляцию.

Еще интереснее - граф объектов.

Простите, но сам по себе «граф объектов» – это как анекдот про «приборы» и «42»

На C++ решается множество задач, где используются графы объектов (например, в САПРах), и вроде решается без особых проблем. Хотя как раз здесь надобность в visitor-ах и проявляется.

Или же речь шла про сериализацию/десериализацию графа?

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

ИМХО, вы говорите в духе «за все хорошее против всего плохого», без конкретики.

Статичная типизация тут немного побоку

Категорически не соглашусь.

самые ООП-шные языки - динамические.

И самые-самые ООП-шные из них – самые тормознутые, достаточно на Ruby посмотреть.

eao197 ★★★★★
()
Ответ на: комментарий от unsigned

Например, выхватить произвольный объект, разобрать на части, передать куда-то, пересобрать.

а каких рутинных задачах надо «разбирать и пересобирать» обьекты-то? чтобы запулить обьект по сети и собрать его там? решается вообще без рефлексий. сбросить обьект в файл, тоже можно без рефлексий.

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

зы. во я практически повторил аргументы предыдущего оратора.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от lovesan

риторический прием - «а вы батенька гавно!»

alysnix ★★★
()
Ответ на: комментарий от eao197

И самые-самые ООП-шные из них – самые тормознутые, достаточно на Ruby посмотреть.

Вы предвзято рассуждаете. Ruby тормоз, потому как никто не парился с его произодительностью. Ну, не нашлось у него своего гугля или фейсбука, которому это было бы критично. А так … вон, JS такой же динамичный, а быстрее на порядок, а то и на два.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

А так … вон, JS такой же динамичный

В JS, насколько я помню, ООП другое. Не классовое, а прототипное. Так что это как апельсины с помидорами сравнивать :)

Но да, в оптимизацию Ruby особо никто не вкладывался. Однако, если сравнить какой-нибудь Python с каким-нибудь Go (не говоря уже про C++), то разрыв все равно существенный.

Не последнюю роль в этом играет тот факт, что в C++ при вызове метода не нужно искать «обработчик» и вызывать условный method_missing в случае, если «обработчик» не был найден.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

А ничего удивительного. VB/Delphi как способ быстро склепать гуйню умер, расчехлять Qt лениво и он очень жирный, а взять ImGui и быстро склепать ui для того чтобы что-то по делу показать - самое оно. Особенно, если нужно не под винду, там хоть шарп взять можно, а фреймворк уже давно в систему вкручен.

Вот на мой взгляд для того, что называлось RAD, по нынешним временам взять просто нечего.

UPD: и ещё кайф в том, что не надо за собой дополнительных либ никаких тащить. Всё с собой.

Dark_SavanT ★★★★★
()
Последнее исправление: Dark_SavanT (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

VB/Delphi как способ быстро склепать гуйню умер, расчехлять Qt лениво и он очень жирный, а взять ImGui и быстро склепать ui для того чтобы что-то по делу показать - самое оно.

Не-не-не. Его применяют не для того, чтобы быстро склепать, а чтобы быстро работало. Например, в приложениях для обработки аудио и видео.

Просто приложения эти под узкую профессиональную аудиторию заточены, там им модный look-and-feel как-то по барабану.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

В приложениях для обработки аудио и видео нахер не всрались кресты. Можно просто взять ffmpeg, дотнет, и всё.

На винде еще можно выводить всю красоту через DirectX, тогда все будет аппаратно ускорено. Им же можно всякие преобразования делать.

Вобщем-то, я так и сделал в свое время.

lovesan ★★
() автор топика
Ответ на: комментарий от eao197

Так оно под то и точёное вроде как. типа «Dear ImGui outputs vertex buffers and a small list of draw calls batches. It never touches your GPU directly. The draw call batches are decently optimal and you can render them later, in your app or even remotely.»

Типа как раз делаем работу, а ui рисуем когда время есть. А уж твоя как программиста задача сделать так, чтобы всё сходилось.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от lovesan

В приложениях для обработки аудио и видео нахер не всрались кресты.

Да-да, послушаем персонажа, который не глядя два раза лезет в map по одному и тому же ключу, а потом рассуждает о тормозах плюсов.

Если у вас даже std::vector тормозит, то лучше бы вам байки про преимущества CL над всем миром продолжать рассказывать.

eao197 ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Типа как раз делаем работу, а ui рисуем когда время есть. А уж твоя как программиста задача сделать так, чтобы всё сходилось.

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

eao197 ★★★★★
()
Ответ на: комментарий от ugoday

Sorry (опять о своих разработках)

Как-то на JavaScript + PHP + XML реализовал парсинг всего MSDN.
С какой целью?
Результат парсинга был в получение исходников (*h, *.cpp (в т.ч. для OLE), *.idl)
биндингов к API всех подсистем и интерфейсов с анализом кодов возврата всех функций.
Так вот связка API + PHP справилась с этой задачей часа за три.

Самое любопытное в том, что в некоторый момент понял, что API Microsoft мне НЕ НУЖНО.

Бывает и так!

Пост был о том, что иногда JavaScript и PHP бывают полезны.

// --------------------------------------------------------
// --- Abandons a specified call on the specified service proxy.
//     
HRESULT WINAPI CWebServices::WsAbandonCall(
 _In_      WS_SERVICE_PROXY  *serviceProxy,
 _In_      ULONG             callId,
 _In_opt_  WS_ERROR          *error
) {
/*
Parameters

serviceProxy [in]      Pointer to a WS_SERVICE_PROXY structure representing the service proxy on which to abandon the call.     

callId [in]            ID of the call to abandon. (See the Remarks section.)                                                    

error [in, optional]   Pointer to a WS_ERROR structure that receives additional error information if the function fails.        


Return value

If the function succeeds, it returns NO_ERROR; otherwise, it returns an HRESULT error code.


Return code              Description
-----------              -----------
WS_E_INVALID_OPERATION   The current state of the service proxy is not valid for this operation.     
                                                                                                     

E_INVALIDARG             A NULL service proxy was passed to the function.                            
                                                                                                     
                                                                                                     

В 


Remarks

Calls are identified by a call ID. This call ID is associated with the call by the WS_CALL_PROPERTY_CALL_ID value of the
WS_CALL_PROPERTY_ID enumeration.

If the call ID is 0, all pending calls on the service proxy are abandoned. For more information, see the following topics:

Be aware that the actual I/O associated with the call is not canceled. The service proxy keeps the resources to complete the call 
even though the call was abandoned.

This results in a consumption of resources that is aggravated if an application continues to abandon calls, as can happen when
the server is slow to respond to the client, and the client application abandons one call only to make the same call again.


*/

 BOOL  bVp1 = TRUE;

 ErrorClear                                                // Clear error datas

HRESULT  $VpHRESULT = ::WsAbandonCall(
  serviceProxy,
  callId,
  error
 );

// --- 
//
 if ( $VpHRESULT == SOCKET_ERROR ) {

  ErrorDataCodeWSA( TRUE, FALSE )                          // Проверка на наличие ошибки

 }

 return  TRUE;                                             // 

}                                                          // HRESULT WINAPI CWebServices::WsAbandonCall(
Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от eao197

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

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

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Щас даже откопал, восстановил зависимости, потыкал - оно работает до сих пор

Вот шо значит обратная совместимость в дуднете! Мощь

https://files.catbox.moe/miivib.png

(сервер тут стримит видео-заглушку вместо камеры, ясное дело, потому что настоящие камеры-тепловизоры уже давно стоят в швейцарии)

lovesan ★★
() автор топика
Ограничение на отправку комментариев: