но мне кажется в чем то вы все таки опять не совсем правы:
никто не может всегдА писать комментарии по делу. Как говорится и на старуху бывает проруха, народная мудрость :). Люди же не машины и вы тоже человек.
Делая такие утверждения вы рискуете начать защищать свои ошибки (если не сейчас, то когда то потом, люди ошибаются) чтобы выполнить свое обещание, поэтому я вам желаю смягчить вашу категоричность.
так это тоже АПИ для работы с библиотекой, только с удаленной, принципиального отличия тут нет. Интерфейсы разных Direct интерфейсов спроектированы в том числе чтобы работать удаленно через любой протокол и тип соединения, но разбираться с этим с нуля по документации конечно достаточно сложно, придется продираться через море не всегда очевидной теории, лучше бы конечно начать с анализа и применения какого-то готового работающего решения, но тут я не знаю что посоветовать, к сожалению.
Но подход с "фабрикой классов" или если уточнить с "фабрикой ендпоинтов" также замечательно будет работать для REST API и для HTTP API, это точно, попробуйте!
Просто перед тем как начать пользоваться запрос определенного типа (рутинный запрос) надо в самом начале при инициализации иметь возможность послать запрос на разрешение использовать этот рутинный запрос, также можно согласовывать состав структур данных для обмена с клиентом или с сервером при запуске и тд итп. Это на самом деле очень небольшой оверхед и только при запуске клиента, но он кардинально решает проблему непонятных сбоев при неотслеженных изменениях софта реализаций.
Проблема в том, что у нас публичное API для клиентов, которые платят деньги :)
Ну я думаю трудно найти какое-то "публичное API для клиентов" более публичное чем DirectX, например.
Вы ведь знаете что такое DirectX (?) и практически все знают кто умеет пользоваться компьютером. Поэтому я думаю вы согласитесь что судить о том насколько ваше "публичное API для клиентов", действительно публичное, мне, и вообще аудитории Хабра, достаточно трудно.
Но да не по полчаса 7мин и 11 мин, но это тоже достаточно много, если учесть еще что это не связанные темы. Хотя вы конечно могли их подготовить заранее...
Была одна статья в которой был сплошной бред про многопоточность, они ее убрали после критики.
я совершенно согласен с вашей оценкой, но в этой конкретной статье хотя бы есть что-то полезное в агрегированной таким образом информации, неужели только за это что-то полезное ее заплюсовали?
Но если это действительно пишет машина то сложно судить хорошо это или плохо, у меня по крайней мере нет таких критериев, а машины тоже надо как-то развивать-тренировать, возможно в этом есть смысл, хотя с внешней, с нашей стороны это действительно выглядит странно, а главное не идет на пользу Хабру, я думаю.
я наблюдаю за этим автором уже наверно год. Он умудряется иногда генерировать по две получасовые статьи в день! При этом успевает отвечать в коментариях в интонациях школьника.
Я думаю это серьезная группа разработчиков отрабатывает-тренерует машину искуственного интелекта на Хабре, не удивлюсь если это проект внутри Хабра.
есть же десятилетиями проверенное решение, клиенты должны реализовать процедуру получения АПИ через которые они хотят работать. Другими словами нужно реализовать 2 типа АПИ: АПИ для доступа к рабочим АПИ, и собственно рабочие АПИ через которые выполняется работа приложения/сервиса/службы/...
АПИ для доступа к рабочим АПИ это реализация шаблона проектирования "фабрика классов", потому что нет другого способа вызова АПИ, как через создание класса реализующего это АПИ.
Да это не решает проблемму работоспособности продукта если АПИ больше не поддерживается, но вы всегда будете знать причину по которой ваше приложение/сервис/служба/... не стало работать, потому что фабрика классов сообщит вам что она теперь не может создать класс нужным вам АПИ и не допустит череды непонятных исключений с которыми непонятно что делать. А перефразируя известную сентенцию: знание причины проблемы, это 95 % ее решения, то есть вы либо будете переориентировать ваше приложение на новый интерфейс, либо напишете претензию поставщику библиотеки (например) с реализациями интерфейсов.
Я как раз пишу про те вещи, которые сам знаю. И я именно потому уверен в их бесполезности, что мне самому они не пригодились.
Так я не знал только название! А то что, как я теперь выяснил, имеется ввиду под этим названием я прекрасно знаю, и так же уверен в бесполезности (ну если вы не разработчик компиляторов конечно!) этого чего-то, что очень трудно определенно сформулировать, судя по количеству приведенных ссылок, и замечания о том что это что-то превратилось в тыкву.
Но вы похоже думаете, что только вам позволено быть увереным в бесполезности чего-то. Извините что помешал вам пребывать в этой уверенности.
если инженер, то какого хрена кичитесь своим незнанием вместо того, чтобы пойти и узнать?
ну у меня действительно до сих пор не было необходимости вникать, что понимают под системой типов. Но я не согласен что это надо определять словом "кичитесь", я бы сказал я этого не стесняюсь.
Я например одно время плотно работал с кодом написанным по COM спецификации не зная про эту спецификацию или не совсем осозновая ее положения, при этом ко мне очередь стояла проконсультироваться по выбору-применению правильных интерфейсов в коде на практике. Очень благодарен одному, тоже кстати недовольному, читателю моей статьи что подсказал мне где прочитать теорию.
Но в отличие от вас я не пропагандирую это свое не знание, как вы это делаете здесь например:
Почему вы на Си остановились? Почему бы ещё ассемблер не выучить, а потом не научиться писать в машинных кодах, и нам закуску коснуться разработки железа? А потом обнаружить, что в фронтенде это всё не помогает вообще никак.
Хотя я тоже не считаю что ассемблер надо прям учить, но знать основы машинных языков точно никому не помешает на мой взгляд, просто потому что это действительно основы всего программирования.
Мне ваши коментарии такого рода напоминают классику:
Зачем изучать географию? Есть же извозчики - довезут куда надо.
Если вы для себя выдумали какие-то свои определения, которые расходятся с общепринятыми, то это ваша проблема.
я ничего не выдумал я интерпретирую смысл словосочетания в соответствии с правилами русского языка. Я не обязан знать ту книжку или сайт по которым вы сейчас работаете. Я не занимаюсь разработкой или тестированием компиляторов в данный момент, поэтому я не обязан идентифицировать значения ваших терминов в соответствии с какими либо правилами кроме правил русского языка.
то есть под системой типов имелась ввиду не система типов, а набор правил по контролю, преобразованию, приведению, ... типов. Мне этого вполне достаточно что бы понять о чем на самом деле речь.
И еще сразу понятно что разговаривать не о чем, так как подмена понятий происходит уже на уровне названий и это ни кого не беспокоит.
Вообще говоря в С или в С++ вы тоже можете посмотреть все локальные переменные и сделать с ними что вам нужно, но только в Дебаге. Если вы не в курсе. Я достаточно часто этим пользуюсь, например. Только я вот, хоть убейте, не понимаю что, по вашему, должна доказать это возможность относительно языка программирования, если даже мы оставим наши разногласия по определениям терминов.
в противном случае идеальным языком был бы sloppy mode javascript
то есть это разговор о поиске идеального языка. А я то думал что всем понятно, что одного идеального языка не существует:
Можно сделать вывод что язык все таки привязан к определенному классу задач ...
как минимум, соответственно нет смысла его искать, по моему.
То есть это я не удачно зашел или, скорее, попал.
Но тут не могу удержаться:
sloppy mode javascript, где можно даже список локальных переменных вычислять в рантайме
во первых, не ужели вы считаете что для javascript есть рантайм? он что компилируемый? Какие локальные переменные вы собираетесь получить после оптимизации на этапе компиляции?
потом, вы сначала говорили про типы, и вдруг переключились на переменные, разве нет разницы между типами и переменными?
если что, в языке Perl который вроде как ровестник С-ей тоже можно получить список локальных и любых переменных, но он точно не компилируемый был.
как то не очень толерантно, можно подумать что сообщество Rust вооружает не понятно кого (или понятно?), то есть кто по вашему является целевой аудиторией пользователей Rust?
После приведенного вами комментария даже название языка в переводе и без начинает играть новыми красками.
Вы бы поосторожнее с аналогиями и аллегориями, тут ведь все записывают. Как говорится все можно использовать против вас!
тут вы наверно заговорились, хороший язык, С++ например, позволяет программисту определять типы, которые конкретно ему нужны для его конкретной задачи, язык не может задать какую-то одну универсальную систему типов для решения любых задач (примитивные типы уже давно перечислены и мало чем отличаются между языками). Возникает вопрос: а что тут можно изобрести если уже есть язык, который это позволяет? Но вот придумали же Java и C#, которые на самом деле сокращают формальности при определении типов, (как минимум хидера писать не надо) + тот же мемори менежмент автоматический как раз. Но для некоторых задач все равно С++, а иногда и чистый С остаются незаменимыми.
Можно сделать вывод что язык все таки привязан к определенному классу задач, и значит если этот класс задач не достаточно понятен будущее языка остается под сомнением.
А вот рассказывать про то что язык вас от чего-то защищает мне кажется не очень конструктивно, потому что любая палка о двух концах как известно, но это мое сугубо субъективное мнение и не только про палку.
Хорошо, спасибо.
но мне кажется в чем то вы все таки опять не совсем правы:
никто не может всегдА писать комментарии по делу. Как говорится и на старуху бывает проруха, народная мудрость :). Люди же не машины и вы тоже человек.
Делая такие утверждения вы рискуете начать защищать свои ошибки (если не сейчас, то когда то потом, люди ошибаются) чтобы выполнить свое обещание, поэтому я вам желаю смягчить вашу категоричность.
вы меня удивляете, комментарий вполне по делу, и может даже когда-нибудь мне пригодится, хотя пока тема у меня не в фокусе.
но у меня еще был вопрос а может ли Ассерт работать в Релизе, бывает ли такое?
Но вы может сюда пришли чтобы просто мне еще один минус поставить, тогда это прикольно. Я совсем вас не понимаю.
так это тоже АПИ для работы с библиотекой, только с удаленной, принципиального отличия тут нет. Интерфейсы разных Direct интерфейсов спроектированы в том числе чтобы работать удаленно через любой протокол и тип соединения, но разбираться с этим с нуля по документации конечно достаточно сложно, придется продираться через море не всегда очевидной теории, лучше бы конечно начать с анализа и применения какого-то готового работающего решения, но тут я не знаю что посоветовать, к сожалению.
Но подход с "фабрикой классов" или если уточнить с "фабрикой ендпоинтов" также замечательно будет работать для REST API и для HTTP API, это точно, попробуйте!
Просто перед тем как начать пользоваться запрос определенного типа (рутинный запрос) надо в самом начале при инициализации иметь возможность послать запрос на разрешение использовать этот рутинный запрос, также можно согласовывать состав структур данных для обмена с клиентом или с сервером при запуске и тд итп. Это на самом деле очень небольшой оверхед и только при запуске клиента, но он кардинально решает проблему непонятных сбоев при неотслеженных изменениях софта реализаций.
Ну я думаю трудно найти какое-то "публичное API для клиентов" более публичное чем DirectX, например.
Вы ведь знаете что такое DirectX (?) и практически все знают кто умеет пользоваться компьютером. Поэтому я думаю вы согласитесь что судить о том насколько ваше "публичное API для клиентов", действительно публичное, мне, и вообще аудитории Хабра, достаточно трудно.
куда же вам еще развиваться то, если вы уже и так в состоянии писать по две статьи в день, или просто очень часто, по десяткам не связанных тем!
Вы меня пугаете :) !
ну вот же:
6 дек 2023 в 18:59
6 дек 2023 в 16:02
5 дек 2023 в 17:25
Но да не по полчаса 7мин и 11 мин, но это тоже достаточно много, если учесть еще что это не связанные темы. Хотя вы конечно могли их подготовить заранее...
Была одна статья в которой был сплошной бред про многопоточность, они ее убрали после критики.
я совершенно согласен с вашей оценкой, но в этой конкретной статье хотя бы есть что-то полезное в агрегированной таким образом информации, неужели только за это что-то полезное ее заплюсовали?
Но если это действительно пишет машина то сложно судить хорошо это или плохо, у меня по крайней мере нет таких критериев, а машины тоже надо как-то развивать-тренировать, возможно в этом есть смысл, хотя с внешней, с нашей стороны это действительно выглядит странно, а главное не идет на пользу Хабру, я думаю.
я наблюдаю за этим автором уже наверно год. Он умудряется иногда генерировать по две получасовые статьи в день! При этом успевает отвечать в коментариях в интонациях школьника.
Я думаю это серьезная группа разработчиков отрабатывает-тренерует машину искуственного интелекта на Хабре, не удивлюсь если это проект внутри Хабра.
есть же десятилетиями проверенное решение, клиенты должны реализовать процедуру получения АПИ через которые они хотят работать. Другими словами нужно реализовать 2 типа АПИ: АПИ для доступа к рабочим АПИ, и собственно рабочие АПИ через которые выполняется работа приложения/сервиса/службы/...
АПИ для доступа к рабочим АПИ это реализация шаблона проектирования "фабрика классов", потому что нет другого способа вызова АПИ, как через создание класса реализующего это АПИ.
Да это не решает проблемму работоспособности продукта если АПИ больше не поддерживается, но вы всегда будете знать причину по которой ваше приложение/сервис/служба/... не стало работать, потому что фабрика классов сообщит вам что она теперь не может создать класс нужным вам АПИ и не допустит череды непонятных исключений с которыми непонятно что делать. А перефразируя известную сентенцию: знание причины проблемы, это 95 % ее решения, то есть вы либо будете переориентировать ваше приложение на новый интерфейс, либо напишете претензию поставщику библиотеки (например) с реализациями интерфейсов.
Так я не знал только название! А то что, как я теперь выяснил, имеется ввиду под этим названием я прекрасно знаю, и так же уверен в бесполезности (ну если вы не разработчик компиляторов конечно!) этого чего-то, что очень трудно определенно сформулировать, судя по количеству приведенных ссылок, и замечания о том что это что-то превратилось в тыкву.
Но вы похоже думаете, что только вам позволено быть увереным в бесполезности чего-то. Извините что помешал вам пребывать в этой уверенности.
ну у меня действительно до сих пор не было необходимости вникать, что понимают под системой типов. Но я не согласен что это надо определять словом "кичитесь", я бы сказал я этого не стесняюсь.
Я например одно время плотно работал с кодом написанным по COM спецификации не зная про эту спецификацию или не совсем осозновая ее положения, при этом ко мне очередь стояла проконсультироваться по выбору-применению правильных интерфейсов в коде на практике. Очень благодарен одному, тоже кстати недовольному, читателю моей статьи что подсказал мне где прочитать теорию.
Но в отличие от вас я не пропагандирую это свое не знание, как вы это делаете здесь например:
Хотя я тоже не считаю что ассемблер надо прям учить, но знать основы машинных языков точно никому не помешает на мой взгляд, просто потому что это действительно основы всего программирования.
Мне ваши коментарии такого рода напоминают классику:
я ничего не выдумал я интерпретирую смысл словосочетания в соответствии с правилами русского языка. Я не обязан знать ту книжку или сайт по которым вы сейчас работаете. Я не занимаюсь разработкой или тестированием компиляторов в данный момент, поэтому я не обязан идентифицировать значения ваших терминов в соответствии с какими либо правилами кроме правил русского языка.
да-тут-вот уже в следующем коменте написано:
то есть под системой типов имелась ввиду не система типов, а набор правил по контролю, преобразованию, приведению, ... типов. Мне этого вполне достаточно что бы понять о чем на самом деле речь.
И еще сразу понятно что разговаривать не о чем, так как подмена понятий происходит уже на уровне названий и это ни кого не беспокоит.
Вообще говоря в С или в С++ вы тоже можете посмотреть все локальные переменные и сделать с ними что вам нужно, но только в Дебаге. Если вы не в курсе. Я достаточно часто этим пользуюсь, например.
Только я вот, хоть убейте, не понимаю что, по вашему, должна доказать это возможность относительно языка программирования, если даже мы оставим наши разногласия по определениям терминов.
то есть это разговор о поиске идеального языка. А я то думал что всем понятно, что одного идеального языка не существует:
как минимум, соответственно нет смысла его искать, по моему.
То есть это я не удачно зашел или, скорее, попал.
Но тут не могу удержаться:
во первых, не ужели вы считаете что для javascript есть рантайм? он что компилируемый? Какие локальные переменные вы собираетесь получить после оптимизации на этапе компиляции?
потом, вы сначала говорили про типы, и вдруг переключились на переменные, разве нет разницы между типами и переменными?
если что, в языке Perl который вроде как ровестник С-ей тоже можно получить список локальных и любых переменных, но он точно не компилируемый был.
мне кажется это какое то отвлечение на негодный объект, то есть перевод темы в непонятном направлении.
чем не нравится сентенция о том что
мне интересно узнать.
Вы тоже считаете что есть какая то универсальная система типов которая позволяет решать любые задачи?
ну можете считать, что я уже жду когда вы меня начнете знакомить, а заодно и весь Хабр.
Ссылку хоть дайте что ли.
как то не очень толерантно, можно подумать что сообщество Rust вооружает не понятно кого (или понятно?), то есть кто по вашему является целевой аудиторией пользователей Rust?
После приведенного вами комментария даже название языка в переводе и без начинает играть новыми красками.
Вы бы поосторожнее с аналогиями и аллегориями, тут ведь все записывают. Как говорится все можно использовать против вас!
тут вы наверно заговорились, хороший язык, С++ например, позволяет программисту определять типы, которые конкретно ему нужны для его конкретной задачи, язык не может задать какую-то одну универсальную систему типов для решения любых задач (примитивные типы уже давно перечислены и мало чем отличаются между языками). Возникает вопрос: а что тут можно изобрести если уже есть язык, который это позволяет? Но вот придумали же Java и C#, которые на самом деле сокращают формальности при определении типов, (как минимум хидера писать не надо) + тот же мемори менежмент автоматический как раз. Но для некоторых задач все равно С++, а иногда и чистый С остаются незаменимыми.
Можно сделать вывод что язык все таки привязан к определенному классу задач, и значит если этот класс задач не достаточно понятен будущее языка остается под сомнением.
А вот рассказывать про то что язык вас от чего-то защищает мне кажется не очень конструктивно, потому что любая палка о двух концах как известно, но это мое сугубо субъективное мнение и не только про палку.
если бы это была именно помощь вопросов бы не было, но вместо помощи часто предлагается просто набор ограничений.
Типа мы вам помогли, теперь вы не можете делать так ... , и так, и так, ...
делайте только так ....