Rust vs C++

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

0

Сообщение от COKPOWEHEU Кроме того, сложно представить квалифицированного программиста, не знакомого хотя бы с азами системного скриптования вроде bash или make.

А этот анахронизм то вообще кому нужен?

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Могу повторить: тензор это закон преобразования. Указатель - абсолютный адрес. Вы утверждаете что они эквивалентны.

Прочитайте уже хотя бы какую то мурзилку по тензорам. Хотя бы вот эту
Тензор = массив компонент + закон преобразования компонент при замене базиса. ..

Добавлено через 48 секунд

Сообщение от COKPOWEHEU И не нашлось ни одного программиста (из тех, что в фантазиях Фулькрума решают 99% задач) чтобы переписать по-другому.

Кто вам это сказал? У нас здесь это легаси давно к распространению запрещено. Да и весь учет на более-менее крупных предприятиях никогда на 1С не велся. Всегда были свои системы без всякой скриптомазни.

Добавлено через 7 минут

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

Начнем с того что хороший системщик никогда не будет отождествлять системное программирование с низкоуровневым. Да практически все, если не все низкоуровневое программирование относится к системному. Но далеко не любое системное программирование низкоуровневое. Системное - это такое которое не привязано к конкретной предметной области, а направленное на решение задач общих для всех прикладных областей. К примеру библиотека контейнеров на С++ или даже библиотека релизующая каналы поверх вебсокета написанная на JS - это точно такое же системное программирование. А по сему в подавляющем большинстве случаев толковый системщик будет выбирать для реализации именно плюсы.

Добавлено через 7 минут

Сообщение от COKPOWEHEU Скажем, раньше я не задумывался что Labview - функциональный язык.

LabView - это вообще не язык, а среда моделирования приборов. А встроенный язык входящий в ее состав называется Гэ. При этом визуальный == декларативный, что далеко не обязательно == функциональный, а вернее если декларативность достигла уровня пригодности к визуальной разработки то != функциональный.

Добавлено через 21 минуту

Сообщение от COKPOWEHEU в коридорах соответствующего института не встречались,

Еще бы. Ваша шарага по ходу даже до универа не доросла.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Чем проще задача

Чем проще задача тем проще решить ее один раз универсально чем хардкодить в нее данные перед каждым запуском.

Добавлено через 10 минут

Сообщение от COKPOWEHEU предпочитая Си

Предпочитая плюсы. Или вы считаете что к примеру наиболее сложное системное ПО такое как СУБД или компиляторы на С пишут? Вы отстали от жизни как минимум на 40 лет.
Речь как раз идет о том что при отсутсвии некоторых ньюансов квалифицированный программист для подавляющего большинства задач будет выбирать именно С++. Исключение составит разве что минорные доделки в большие уже существующие системы на фортране или аде. Ньюанс здесь один - дабы не разводить зоопарк.

0

Сообщение от Fulcrum_013 C каких пор С++ или С перестали быть высокоуровневыми?

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

Сообщение от Fulcrum_013 А этот анахронизм то вообще кому нужен?

Всем, кто работает с компьютером, а не на нем. Попробуйте, вам понравится.

Сообщение от Fulcrum_013 Прочитайте уже хотя бы какую то мурзилку по тензорам. Хотя бы вот эту

Читаю вслух, специально для Fulcrum_013:

Те́нзор (от лат. tensus, «напряжённый») — объект линейной алгебры, линейно преобразующий элементы одного линейного пространства в элементы другого.

Не знаю уж как еще понятнее описать что тензор - закон преобразования из одних единиц в другие.

Сообщение от Fulcrum_013 [1c] Кто вам это сказал?

https://lmgtfy.com/?q=1%D1%81+%D0%B2%D0%B0%D0%BA%D0%B0%D0%B D%D1%81%D0%B8%D0%B8

Сообщение от Fulcrum_013 К примеру библиотека контейнеров на С++ или даже библиотека релизующая каналы поверх вебсокета написанная на JS - это точно такое же системное программирование. А по сему в подавляющем большинстве случаев толковый системщик будет выбирать для реализации именно плюсы.

Ну если подгонять определение под ответ, то конечно. Если системщиком назвать разработчика библиотеки контейнеров С++, то да, он будет пользоваться С++, кто бы спорил.
Вот только речь не о них.

Сообщение от Fulcrum_013 LabView - это вообще не язык, а среда моделирования приборов. А встроенный язык входящий в ее состав называется Гэ.

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

Сообщение от Fulcrum_013 Еще бы. Ваша шарага по ходу даже до универа не доросла.

Я понимаю, что для вас все, что не С++ и не учебные заведения демагогов находится где-то на уровне нуля или даже ниже. Так что да, по вашей классификации всякие МГУ, физтехи, бауманки и прочие недо-вузы даже рассмотрения не заслуживают. Ну что-ж, придется им смириться.

Сообщение от Fulcrum_013 Чем проще задача Чем проще задача тем проще решить ее один раз универсально чем хардкодить в нее данные перед каждым запуском.

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

Сообщение от Fulcrum_013 Речь как раз идет о том что при отсутсвии некоторых ньюансов квалифицированный программист для подавляющего большинства задач будет выбирать именно С++.

Как вы ловко объявили "нюансами" (да, мягкого знака в этом слове нет) типичные требования! А так да, если человек знает только С++, то для любой задачи он его и будет использовать. Правда, то же самое можно сказать и о любом другом языке...

0

Сообщение от COKPOWEHEU Не знаю уж как еще понятнее описать что тензор - закон преобразования из одних единиц в другие.

Да никак. Тензор это совокупность компонент и закона преобразования.

Добавлено через 6 минут

Сообщение от COKPOWEHEU Тут та же проблема что с msvs: если обозвать язык по среде, гораздо проще объяснить что имеется в виду. Вон ведь даже вы поняли, а это о многом говорит.

Это говорит только о том что вся эта LabVIEW в купе с ее Гэ - не более чем плохая породия на CASE-технологию. Причем поимевшая эпический фейл на маркетплейсе.
А развивается версия со встроенным С, что за исключением возможности расширять набор компонентов на ней же делает ее практически аналогичной С++ Builder.
Так же это говорит о том что с тем что делается путем примитивнейшего формошлепства - т.е. размещения на форме элементов и визуального биндинга каналов ваши физики еще кое как делают, а вот как дело доходит до обработчиков событий сразу требуют квалифицированного специалиста - и правильно делают - назначение CASE технологий не в каком то снижении порога вхождения, а в повышении продуктивности профессионалов.

Добавлено через 3 минуты

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

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

Добавлено через 8 минут

Сообщение от COKPOWEHEU А так да, если человек знает только С++, то для любой задачи он его и будет использовать.

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

Добавлено через 5 минут

Сообщение от COKPOWEHEU По существу: этих мелких задач настолько много, что на поиск готового решения уйдет больше сил, чем на решение.

Абсолютно все задачи которые стоят к примеру перед разрабом софта в этом плане прекрасно решает IDE, причем гораздо лучше анахронизма cmake. Потому что построение списка билда - это таки задание исходных данных. То же самое в принципе касается и всего остального. К примеру задачи развертывания софтин гораздо лучше решают инсталл-шиелды чем всякие баши и т.д., а особенно задачу построения средства развертывания. Причем по той же самой причине - это на 100% делается путем конфигурирования данными. А соответсвенно хардкодинг данных которые подразумевает баш для таких дел - это полнейшее УГ.

Добавлено через 8 минут

Сообщение от COKPOWEHEU Ну если подгонять определение под ответ, то конечно.

Это именно определение именно системного программирования.Хоть бы мурзилку прочитали, раз академии у вас деревообрабатывающие. Там перечисленно что к системному софту относится. К примеру абсолютно все библиотеки/api вне зависимости от их уровня - это системный софт.
Точно так же как к примеру текстовый редактор или IDE.

Добавлено через 11 минут

Сообщение от COKPOWEHEU Так что да, по вашей классификации всякие МГУ, физтехи, бауманки и прочие недо-вузы даже рассмотрения не заслуживают

Особенно бауманки. Шарашку где программисты до сих пор начерталку чертят а не вычислительной геометрией и геометрическим моделированием эти вопросы решают вообще ВУЗ-ом назвать сложно.

Добавлено через 9 минут

Сообщение от COKPOWEHEU [1c]https://lmgtfy.com/?-1%D1%81+%D0%B2%D0%B0%D0%BA%D0%B0%D0%BD%D 1%81%D0%B8%D0%B8

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

Добавлено через 13 секунд

Сообщение от COKPOWEHEU [1c]https://lmgtfy.com/?-1%D1%81+%D0%B2%D0%B0%D0%BA%D0%B0%D0%BD%D 1%81%D0%B8%D0%B8

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

Добавлено через 13 минут

Сообщение от COKPOWEHEU Тут та же проблема что с msvs: если обозвать язык по среде, гораздо проще объяснить что имеется в виду.

Та нет все по разному. MSVC это тот же С++, причем единственное что не понятно - это с какой стороны оно Visual. Точно так же как и С++ Builder это тот же С++. Точно так же как и Qt это тот же С++. Другие только IDE и дополнительные искоробочные библиотеки, при этом у Qt и компилятора то в комплекте нет - юзает сторонний. Ну правда поддержка свежего стандарта заходит не во всех одновременно.
При этом в одной и той же среде могут использоваться разные языки. К примеру дельфа в той же RAD Studio живет что и С++ Builder. Да и в Visual Studio всякое убожество типа СX и C# тоже тусуется. Кстати и компиляторов плюсов в вижаке искоропки два разных. И еще другие сторонние установить можно. А под линуху - так тока сторонним на линукс-хост компилить отправляет.
Добавлено через 1 час 0 минут

Сообщение от COKPOWEHEU Всем, кто работает с компьютером, а не на нем. Попробуйте, вам понравится.

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

0

Сообщение от Fulcrum_013 Да никак. Тензор это совокупность компонент и закона преобразования.

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

Сообщение от Fulcrum_013 Это говорит только о том что вся эта LabVIEW в купе с ее Гэ - не более чем плохая породия на CASE-технологию.

Это говорит о том, что многие путают IDE и язык. И для понимания о чем речь зачастую лучше использовать именно название IDE. А то, что вы там пытаетесь привязать, к этому отношения не имеет.

Сообщение от Fulcrum_013 Вы б хотя бы опять же с мурзилками ознакомились. Высокоуровневое - это все что не в машкоде/мнемониках машкода.

Именно. А поскольку С/С++ оперируют ровно теми же понятиями, называть их высокоуровневыми несколько оптимистично. Напомню: высокоуровневый язык не оперирует терминами реальной или виртуальной машины, он вообще может не знать что такое память.

Сообщение от Fulcrum_013 Ошибаетесь. Плюсы далеко не первый язык который я изучил. Если точнее - то четвертый. При этом далеко не последний в списке освоенных, а по большому счету был ключом к тому чтобы любой язык осваивался за день-два - достаточно просто прочитать в мануале чего нет из того что есть в плюсах.

Вопросов больше нет. Если на изучение языка уходит день-два, и те тратятся лишь на поиск "чем именно он хуже С++" - не удивительно почему у вас настолько поверхностные представления о программировании. Это как говорили "программист на Фортране может на любом языке писать на Фортране", так и вы пытаетесь на любом языке писать на С++, удивляетесь что не получается и радостно декларируете, что язык никуда не годен.

Сообщение от Fulcrum_013 Вот именно поэтому квалифицированные спецы и выбирают плюсы

Не примазывайтесь к спецам.

Сообщение от Fulcrum_013 Абсолютно все задачи которые стоят к примеру перед разрабом софта в этом плане прекрасно решает IDE, причем гораздо лучше анахронизма cmake.

Если вы такое утверждаете, вы явно не сталкивались с хоть немного нетривиальными задачами. Как там хотя бы с простейшими действиями вроде параллельной сборки или сборки одновременно под несколько платформ?
Ну и симметрично - под мои задачи пока что хватает обычного make, на ограничения я пока не наткнулся (ну, кроме мозговыносящего языка программирования, конечно). Чего конкретно я на нем не могу сделать?

Сообщение от Fulcrum_013 К примеру задачи развертывания софтин гораздо лучше решают инсталл-шиелды чем всякие баши и т.д.

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

Сообщение от Fulcrum_013 Абсолютно очевидно что С представитель древних процедурных языков, которые по большому счету не более чем переносимые ассемблеры. С++ же -

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

Сообщение от Fulcrum_013 Хоть бы мурзилку прочитали, раз академии у вас деревообрабатывающие.

Может, вы, наконец, будете сами читать свои же ссылки, краснодипломник деревоутилизирующей академии?
Что ни ссылка так пируэт в лужу:
Ссылка на рост объема кода винды и линукса - опровергает ваши фантазии.
Ссылка на тензор - опровергает ваши слова.
Ссылка на системное программирование - опровергает ваши слова.
Не надоело еще позориться?

Сообщение от Fulcrum_013 Так что да, по вашей классификации всякие МГУ, физтехи, бауманки и прочие недо-вузы даже рассмотрения не заслуживают Особенно бауманки. Шарашку <...> вообще ВУЗ-ом назвать сложно.

Ок, записано.

Сообщение от Fulcrum_013 [1с] Ну о чем и речь - набыдлокодили так что вместо снижения трудозатрат на учет получается их увеличение.

То есть вы утверждаете, что вся эта толпа бизнесов полные дураки и вместо того чтобы нанять богоподобного Fulcrum_013'а плачут, колются и продолжают заказывать кривые подпорки для кривых подделок. Не слишком страшно жить, считая себя Дартаньяном?

Сообщение от Fulcrum_013 Та нет все по разному. MSVC это тот же С++

Если бы речь шла просто о С++, необходимости в уточнениях бы не было, но иногда нужно уточнить вполне конкретный набор багов, специфичный именно для майкрософтовского компилятора. Ну и с CBuilder вы угадали - иногда бывает нужно сделать акцент не на самом языке, а на IDE + языке + стандартных для данной связки библиотеках.

Сообщение от Fulcrum_013 Я лучше по классическому принципу - человек думает, машина работает.

А вы в это время что делаете? Не иначе, стоите рядом (к реальной-то работе не допускают), делаете умное лицо и даете глупые советы.

0

Сообщение от COKPOWEHEU Ссылка на тензор - опровергает ваши слова.

Вы ее вообще прочитали млин и разобрались что означают правила преобразования?
Для самых одаренных - еще раз по этой ссылке выделенно жирным шрифтом:

тензор = массив компонент + закон преобразования компонент при замене базиса.

Или там со второй букофки начинаются непонятниевые для безграмотного COKPOWEHEU и вы их прочитать не осилили?

Добавлено через 5 минут

Сообщение от COKPOWEHEU Ссылка на системное программирование - опровергает ваши слова.

И где она опровергает?
Еще раз по приведенной ссылке список того что входит в системное программное обеспечение:
Операционные системы
Встроенные программы
Утилиты
Системы программирования - т.е. кроме компиляторов VM и ратаймов еще и:
текстовые редакторы — компьютерные программы, предназначенные для создания и изменения текстовых файлов, а также их просмотра на экране, вывода на печать, поиска фрагментов текста и т. п.;
специализированные редакторы исходных текстов — текстовые редакторы для создания и редактирования исходного кода программ. Специализированный редактор исходных текстов может быть отдельным приложением, или быть встроен в интегрированную среду разработки;
библиотеки подпрограмм — сборники подпрограмм или объектов, используемых для разработки программного обеспечения;
редакторы графического интерфейса.
Системы управления базами данных

Т.е. вы читать не умеете от слова совсем да?

Добавлено через 1 минуту

Сообщение от COKPOWEHEU стандартных для данной связки библиотеках

Они там кстати прекрасно заменяемы. На самом деле их там давно две разных.

Добавлено через 7 минут

Сообщение от COKPOWEHEU То есть вы утверждаете, что вся эта толпа бизнесов полные дураки и вместо того чтобы нанять богоподобного Fulcrum_013'а плачут, колются и продолжают заказывать кривые подпорки для кривых подделок

Плачют колятся и продолжают жрать кактус потому что нанять спецов/купить годный софт не в состоянии по финансам - у мелких контор ничего годного вообще быть не может. У более-менее крупных контор, в которых подготовкой данных и машинным счетом занимается соответсвующий отдел, реалии абсолютно другие. Их этот быдлокод от 1С не устраивает в принципе, только сделанный по всем научным правилам софт. Если к примеру на 40k народу счет зарплаты счет запорете то разгребать это будете месяцы. Поэтому никакая скриптомазня там не приемлема в принципе. Только то как это реально делается в реальной бухгалтерии - к примеру для расчета з/п - путем указания таблиц начислений и удержаний. Сами элементы таблиц тоже конфигурируются данными. Кстати так по опыту скажу - это вполне осиливаемо толковым 10-классником с тулзами времен начала 90-х.

Добавлено через 11 минут
А касательно 1С - ну у нас ее распространение давно запрещено. При этом даже при том что установленные ранее копии еще продолжают кое-где использовать количество вакансий не превышает 200 в год на всю страну.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU А вы в это время что делаете?

А я его озадачиваю.

Добавлено через 14 минут

Сообщение от COKPOWEHEU То есть абстракция там повыше, конечно, но до ЯВУ далеко.

Что вы в таком случае называете ЯВУ? Тока не надо нести бред про жабу и тем более скрипты. Они то как раз бедолаги средств как создания так и использования абстракций лишены напрочь. Даже кастомные правила разыменования в указатель засунуть анриал, не говоря уже про автоматику управления взаимосвязям и т.д.

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

Т.е. вы С++ даже в глаза не видели, разве что "С с классами". Плюсы от них отличаются кардинально. Настолько кардинально, что программа на плюсах на самом деле занимается генерацией программы на "С с классами" в компайлтайме. Ни у каких жаб и прочих с понтом "уберязыков" ничего подобного в плане абстракций нет и близко - вся их типа абстрактность - рекламный миф. По средствам создания абстракций жаба и шарп абсолютно анологичны Симула-67. Про скрипты там вообще отсталость - окромя десятка операторов в подавляющем большинстве случаев вообще нифига нет.

Добавлено через 7 минут

Сообщение от COKPOWEHEU Не надоело еще позориться?

Вам еще позорится не надоело тем что не в состоянии даже прочитать то что в мурзилках написано?

0

Сообщение от Fulcrum_013 Вы ее вообще прочитали млин и разобрались что означают правила преобразования?

Я ее вам вслух прочитал, неужели даже после этого непонятно?!
Более того, в отличие от вас, я не только читал (чего вы до сих пор не сделали), но и использовал.
Еще раз: тензор это закон расчета реакции по воздействию. Отличие от аффинных преобразований в том что размерности могут отличаться. Тот же тензор пьезокоэффициентов переводит внешнее воздействие деформации (вектор 3х3 либо 1х6) в разность потенциалов (вектор 1х3). Он записывается матрицей 3х3х3 либо 3х6 и является константой для данного материала. Это не отменяет что его самого можно повернуть на любой угол вокруг любой оси.
И в очередной раз спрашиваю: каким именно противоестественным способом вы пытаетесь притянуть номер ячейки, который по определению переменная, к тензору, который является законом преобразования?
При желании тензором можно обозвать сам массив. Да, он преобразует индекс ячейки (который далеко не всегда номер) в адрес в памяти (тоже не всегда скаляр). Именно это иллюстрируется моим примером: y = &(A[i]). i - индекс массива, воздействие; A - тензор, закон преобразования; y - адрес в памяти, реакция.

Сообщение от Fulcrum_013 Еще раз по приведенной ссылке список того что входит в системное программное обеспечение: Операционные системы, Встроенные программы, Утилиты, Системы программирования (текстовые редакторы, специализированные редакторы исходных текстов, библиотеки подпрограмм, ...) редакторы графического интерфейса. Системы управления базами данных

Подавляющее большинство из этого относится именно к низкому уровню. Разве что базы данных и IDE непонятно почему сюда включили, ну да ладно, все равно близкие понятия.
В любом случае, основная задача системного (ядерного) программирования - высокая надежность и высокая производительность. Поэтому и используется там преимущественно Си, причем с минимумом остроумия вроде ООП.

Сообщение от Fulcrum_013 Они там кстати прекрасно заменяемы. На самом деле их там давно две разных.

Опять Капитан покусал? Естественно, в софте, который пишут разумные люди, компоненты будут заменяемы. Хотя бы на случай обновления своего же софта.
Но как это опровергает исходное высказывание что если нужно уточнить конкретную комбинацию (msvs + тамошний компилятор) либо (Labview + тамошний язык программирования) либо (CBuilder + тамошний набор компонентов), в которых распиарена именно среда разработки, а не кишки, то и именовать ее стоит по среде разработки, подразумевая все остальное?

Сообщение от Fulcrum_013 Плачют колятся и продолжают жрать кактус потому что нанять спецов/купить годный софт не в состоянии по финансам - у мелких контор ничего годного вообще быть не может.

Так, хорошо. То есть нанять мега-хакера-плюсовика они не могут. А что им тогда делать?

Сообщение от Fulcrum_013 А я его озадачиваю.

Вот уж в чем не сомневаюсь! Как ляпнете - не то что программиста, машину озадачите. Жаль, только не задачей, которую они решают...

Сообщение от Fulcrum_013 Что вы в таком случае называете ЯВУ?

Так вроде говорил уже - язык, оперирующий абстрактными понятиями, не привязанными к машине.
Ассемблер оперирует регистрами, памятью, прерываниями, инструкциями. То есть терминами реальной машины. Это низкоуровневый язык.
Си, С++, Паскаль и многие другие оперируют указателями, памятью, переменными конечного размера. Это "среднеуровневые" языки.
Bash, Python оперируют абстрактными переменными, не привязанными к машине, не оперируют памятью. Это высокоуровневые языки.
А то, что в С++ или Ассемблере возможно при желании создать объект чего угодно ничего не говорит об уровне самого языка.
Все ваши восхищения возможностями ручного управления памятью это именно работа на низком уровне. ЯВУ это напротив старательно прячут от программиста. В какой-нибудь Lua вообще нет оператора удаления объекта.
Не подумайте (...о чем это я, вы же и не пытались...) что я имею что-то против низкоуровневого программирования. Напротив, это очень интересная тема. Но не будучи фанатиком, я понимаю, что одним низким уровнем IT не исчерпывается. Более того, я понимаю, что мой подход далеко не самый эффективный, поэтому окружающим я его не навязываю.

Сообщение от Fulcrum_013 Про скрипты там вообще отсталость - окромя десятка операторов в подавляющем большинстве случаев вообще нифига нет.

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

0

Сообщение от COKPOWEHEU Подавляющее большинство из этого относится именно к низкому уровню.

К низкому уровню из этого относится лишь мизерная доля кода ядра и драйверов ОС. Все остальное делается на высоком уровне. Особенно это касается компиляторов, библиотек, десктопных фреймверков, СУБД и т.д. и т.п.

Добавлено через 1 минуту

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

Ну дак и Си и Фортран и планкалкуль не привязаны к машине. Код с них компилируется в любую систему команд.

Добавлено через 10 минут

Сообщение от COKPOWEHEU Ассемблер оперирует регистрами, памятью, прерываниями, инструкциями. То есть терминами реальной машины. Это низкоуровневый язык.

Да. Он привязан к системе команд конкретного процессора и программа на нем не переносима на другой.

Сообщение от COKPOWEHEU Си, С++, Паскаль и многие другие оперируют указателями, памятью, переменными конечного размера. Это "среднеуровневые" языки. Bash, Python оперируют абстрактными переменными, не привязанными к машине, не оперируют памятью. Это высокоуровневые языки. А то, что в С++ или Ассемблере возможно при желании создать объект чего угодно ничего не говорит об уровне самого языка.

А вот это уже абсолютный бред высосанный непонятно откуда. Высокоуровневый - это переносимый между машинами без переписывания кода.
https://ru.wikipedia.org/wiki/... ммирования

Высокоуровневые языки программирования были разработаны для платформенной независимости сути алгоритмов. Зависимость от платформы перекладывается на инструментальные программы — трансляторы, компилирующие текст, написанный на языке высокого уровня, в элементарные машинные команды (инструкции). Поэтому, для каждой платформы разрабатывается платформенно-уникальный транслятор для каждого высокоуровневого языка, например, переводящий текст, написанный на Delphi в элементарные команды микропроцессоров семейства x86. Примеры: C, C++, C#, Delphi, Fortran, Java, JavaScript, Лисп, Паскаль, PHP.

Никакого среднего уровня не существует. Это не более чем бред безсовестных евангелистов национальных быдлоскриптов пиндостана. Так же как не существует и языков не работающих с памятью не разыменовывающих указатели и т.д. и т.п




.

Добавлено через 7 минут

Сообщение от COKPOWEHEU Все ваши восхищения возможностями ручного управления памятью это именно работа на низком уровне. ЯВУ это напротив старательно прячут от программиста. В какой-нибудь Lua вообще нет оператора удаления объекта. Не подумайте (...о чем это я, вы же и не пытались...) что я имею что-то против низкоуровневого программирования. Напротив, это очень интересная тема. Но не будучи фанатиком, я понимаю, что одним низким уровнем IT не исчерпывается. Более того, я понимаю, что мой подход далеко не самый эффективный, поэтому окружающим я его не навязываю.

Все это никакого отношения к делению ЯП на высокоуровневые и низкоуровневые не имеет от слова совсем - все это высокоуровневые языки.
Касательно же всего остального - то что имеет мусоросборник вместо автоматики - это анахронизм, устаревший по сотоянию на 1967-ой год - средств автоматического управления жизненным циклом ресурсов и объектов они не имеют.
А вот ручное управление памятью - это средство построения кастомизируемых сверхвысокоуровневых абстракций, которых эти ваши "уберязыки", лишены напрочь. Не может быть кастомизации и никакой абстракции алгоритмов автоматики управления ресурсами если один из ресурсов управляется не так как остальные, или вообще не доступен к управлению.
А вот эти средства автоматики как раз и позволяют абстрагироваться от управления жизненным циклом и от правил разыменования конкретно взятого типа укзателя, чего эти ваши манаджед ошибки природы лишены напрочь.

Добавлено через 12 минут

Сообщение от COKPOWEHEU Еще раз: тензор это закон расчета реакции по воздействию.

Еще раз - тензор это средстов преобразования любых объектов. То что вы там преобразовывали - это и есть массив копонент - т.е. сам объект. А правила преобразования - это даже не матрицы смены базиса, это привязка компонентов к матрицам смены базиса - часть компонентов при смене может преобразовываться по ковариантнай матрице а другая часть по контрвариантной. Так что идите учите матчасть хотя бы по мурзилке
Выдержки для самых тугоголовых COKPOWEHEU:

Тензор определяется как геометрический объект, который описывается многомерным массивом, то есть набором чисел, занумерованных несколькими индексами, или, иначе говоря, n-мерной таблицей, где n — валентность тензора (см. выше). Так, вектор (тензор первого ранга) задаётся одномерным массивом, либо в виде строки, либо в виде столбца, а такие объекты, как линейный оператор и квадратичная форма, — двумерной матрицей, Скаляр же (тензор нулевого ранга) задаётся одним числом x, которое можно рассматривать как сокращённую запись нульмерного массива с единственным элементом.. Такие нульмерные матрицы удобно рассматривать в качестве частных случаев тензоров, так как все тензорные определения и теоремы для них в силе, и векторы со скалярами можно при общем рассмотрении не упоминать отдельно. тензор = массив компонент + закон преобразования компонент при замене базиса.

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

0

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

Бред от его многократного повторения не станет реальностью.

0

Сообщение от IamLost Бред от его многократного повторения не станет реальностью.

Ну покажи где у GC средства автоматики позволяющие управлять жизненным циклом объектов и ресурсами, раз такой безграмонтный что этого до сих пор не знаешь что он для этого не предназначен и по сему абсолютно не пригоден. Именно у GC. Try with resources к GC абсолютно никакого отношения не имеет, а являются куцым обрубком смартпоинтера, который и задачу не решает в полном обьекме, и по большому счету лучшая демонстрация бесполезности GC.
А если не можешь показать каким образом GC освобождает от обязанности деинициализировать объекты и ресурсы вручную (т.е. на каждом шагу писать вызова абсолютно анологичные ручным вызовам delete) - иди и татуируй у себя на лбу надпись манаджед-быдлокодер.

0

Сообщение от Fulcrum_013 К низкому уровню из этого относится лишь мизерная доля кода ядра и драйверов ОС.

Вообще-то, подавляющая часть. Но с вашим умением придумывать проценты из головы это может быть и 1%, и 10%, и 256%.

Сообщение от Fulcrum_013 Особенно это касается компиляторов, библиотек

И снова в лужу: компиляторы стараются писать на том же языке, который они компилируют. С библиотеками аналогично.

Сообщение от Fulcrum_013 Ну дак и Си и Фортран и планкалкуль не привязаны к машине. Код с них компилируется в любую систему команд.

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

Сообщение от Fulcrum_013 Высокоуровневый - это переносимый между машинами без переписывания кода. https://ru.wikipedia.org/wiki/... ммирования

Под такое определение подходят только интерпретируемые и JIT-компилируемые языки, и то не всегда. Впрочем, они действительно обычно оказываются более высокоуровневыми, чем С, С++, Паскаль.

Сообщение от Fulcrum_013 Никакого среднего уровня не существует.

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

Сообщение от Fulcrum_013 А вот ручное управление памятью

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

Сообщение от Fulcrum_013 Еще раз - тензор это средстов преобразования любых объектов.

Ну наконец-то!
Правда, не любых объектов, а только совместимых, но не суть.
А теперь ответьте наконец, как у вас переменная вдруг стала средством преобразования?

0

Сообщение от COKPOWEHEU Вообще-то, подавляющая часть.

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

Добавлено через 27 секунд

Сообщение от COKPOWEHEU Ну наконец-то!

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU А теперь ответьте наконец, как у вас переменная вдруг стала средством преобразования?

Еще раз для самых одаренных - тензор = объект + правила преобразования. Все вместе - средство преобразования объекта.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU это признак низкоуровневого кода,

Абсолютно нет. В отличии от к примеру работы непосредственно с переменными примитивных (встроенных в язык) типов.

Добавлено через 13 минут
В отличии от к примеру отсутсвия всякого присутсвия алгебры над сущностями предметной области - т.е. работы непосредственно с переменными примитивных (встроенных в язык) типов.

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

А с каких пор размер переменных стал зависеть от платформы? Именно это высокоуровневые языки и скрывают. размер переменных задается в стандарте языка, а туда попадают из более общих стандартов. long как был 4 байта на x16так и остался 4 байта и на x32 и на x64. А еще гораздо жестче стандартизированы типы с плавающей точкой.
Или с каких пор алгоритмы оперирования памятью стали зависимым от платформы? Оперировать с памятью вы будете даже производя вычисления мелом на доске или ручкой на бамашке. Причем по абсолютно тем же самым алгоритмам. Все остальные различия скрывают опять же библиотечные средства ОС.
При этом к примеру у всех современных универсальных языков есть полноценные средства вообще от встроенных типов абстрагироваться как душенька пожелает, в отличии от того то вы называете ЯВП, в которых этих средств либо нет от слова совсем либо для практического применения абсолютно не пригодны.
Т.е. мараль сей басни такова - язык не пригодный к системному программированию (т.е не пригодный к написанию библиотечных средств для самого себя) о какой то там сверхвысокоуровневости может даже не мечтать - он не может дать программисту возможность алгебру над сущностями предметной области - т.е. абстрагироваться от встроенных типов и встроенной же алгебры над ними.

Добавлено через 9 минут
Т.е. мараль сей басни такова - язык не пригодный к системному программированию (т.е не пригодный к написанию библиотечных средств для самого себя) о какой то там сверхвысокоуровневости может даже не мечтать - он не может дать программисту возможность определить алгебру над сущностями предметной области - т.е. абстрагироваться от встроенных типов и встроенной же алгебры над ними. Точно так же как язык не имеющий автоатики управления жизненным циклом, может не мечтать об абстрагировнии от ручного управления ресурсами, ручной реализации поведения каждой взаимосвязи, и т.д. и т.п геморров которые и не дают сконцентриоваться на задаче.

Добавлено через 14 минут

Сообщение от COKPOWEHEU "высокоуровневость" это относительное понятие, но приблизительную оценку я привел.

Нет. Это абсолютное понятие. Либо это язык на котором код пишется для конкретного проца, либо этот код переносим на другой проц.
А то что вы пытаетесь непонятно откуда высасать про какую то относительность - это не более чем бред безсовестных евангелистов национальных быдлоскриптов западного пендостана.
При этом при детальном рассмотрении в деле как создания так и использования высокоуровневых абстракций эти заподнопендостанские ошибки природы проигрывают всухую.
Тут весь сыр бор с этими высосанными из пальца "преимуществами" следует в другом месте искать - все универсальные ООП языки сделаны европейцами. Первая попытка американцев оказалась ущербным убожеством, автор которой умудрился как истинный бледнолицый, как поймать абсолютно все грабли первого европейского ООП-языка, от проблем которого оные языки созданные европейцами успешно избавились лет за 10 до, так и притащить кучу нового гемора исключающего применение средств как создания так и использования высокоуровневых абстракций, и при этом потерять универсальность языка. Но поскольку наконец то амеры сделали свой национальный ООП язык его сначала впихнули в школы. А потом уже в дело пришлось пускать маректинг - ну не могут же в американских школах детей учить неюзабельному гавнищу и не может же оракл двигать отстой, и не может же национальная жаба америки во всем уступать поделкам каких то датчан, норвежцев и французов. От и несут рекламный бред про то какое оно де "сверхабстрактное" искаропки, и про какое то мифическое "общего назначения".

0

Сообщение от Fulcrum_013 Вообще то исключительно небольшая. Нечего в апи низкоуровневым делам делать.

Вообще-то, подавляющая. Именно поэтому интерфейс АПИ процедурный. Ну и потому что нужна надежность, а не рюшечки плюсов.

Сообщение от Fulcrum_013 НУ вот я вам это с самого начала и толдычу. Вы же как баран уперлись в какие то реакции.

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

Сообщение от Fulcrum_013 [ручная работа с памятью] это признак низкоуровневого кода, Абсолютно нет

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

Сообщение от Fulcrum_013 В отличии от к примеру работы непосредственно с переменными примитивных (встроенных в язык) типов.

Если я правильно понял ту кашу, что вы вывалили на форум, работа со встроенными в язык типами - признак низкоуровневого кода, а с объектами предметной области - высокоуровневого. Не буду цепляться к тому, что любой язык по определению умеет работать со своими встроенными типами, очевидно имелись в виду машинные типы.
Да, по этому определению С++ тоже низкоуровневый. Для него базовыми типами являются машино-специфичные. В отличие от, скажем, Питона, где размер числа вообще не ограничен. То есть там числовая переменная это именно числовая переменная, а не ячейка размером 16-64 бита.
И нет, возможность накрутить абстракции на это не влияет.

Сообщение от Fulcrum_013 А с каких пор размер переменных стал зависеть от платформы? Именно это высокоуровневые языки и скрывают.

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

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

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

Сообщение от Fulcrum_013 При этом к примеру у всех современных универсальных языков есть полноценные средства вообще от встроенных типов абстрагироваться

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

Сообщение от Fulcrum_013 Т.е. мараль сей басни такова - язык не пригодный к системному программированию<...> о какой то там сверхвысокоуровневости может даже не мечтать

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

Сообщение от Fulcrum_013 заподнопендостанские ошибки природы проигрывают всухую. Тут весь сыр бор с этими высосанными из пальца "преимуществами" следует в другом месте искать - все универсальные ООП языки сделаны европейцами.

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

0

Сообщение от COKPOWEHEU Нет, вы талдычите какую-то чушь про то, что указатель это и есть тензор.

Указатель есть тензор. потому что его суть от смены СК не меняется - он указывает на один и тот же объект. Меняются только праила разыменования и больше ничего. А соответсвенно и все те же вопросы с арифметикой и т.д. При этом арифметика адресов массивов гораздо опаснее арифметики указателей. Указатели друг с другом не сложишь и чушт не получишь как индексы.
Т.е. к примеру для индекса I преобразование в глобальное адресное пространство осуществляется умножением на метрический тензор адресного пространства определяемый массивом a. т.е. правило его преобразования в конечном итоге получается (a+i)

Добавлено через 31 минуту

Сообщение от COKPOWEHEU Если я правильно понял ту кашу, что вы вывалили на форум, работа со встроенными в язык типами - признак низкоуровневого кода,

Сообщение от COKPOWEHEU Не буду цепляться к тому, что любой язык по определению умеет работать со своими встроенными типами

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

Сообщение от COKPOWEHEU забота языка

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

Добавлено через 6 минут

Сообщение от COKPOWEHEU С момента появления, очевидно. В низкоуровневых языках размер стандартных типов данных привязан к машине, в высокоуровневых - нет.

Ну да. ассемблеры и JavaScript высокоуровневыми не являются.
А у С С++ паскаля и прочих нативных языков размер не зависит от платформы - он задан в стандарте языка, исключение составляет разве что размер указателя. Но от этой разницы никакой язык избавится не сможет в принципе - так или иначе но под капотом объектов он будет хранить нативные указатели а значит размер объектов будет меняться. Он к примеру у паскаля сколько времени был только вообще нестандартный 48-битный Real, причем жил он таким 48-битным на любом железе. Да и сейсас вроде еще живеt всех живых. Так что все ваши инсенуации ни о чем.

Добавлено через 7 минут

Сообщение от COKPOWEHEU И нет, возможность накрутить абстракции на это не влияет.

Влияет и еще как. Если нужна длинная арифметика то есть мульен вариантов как ее реализовать и главное какие требования к этой реализации выдвигаются. И оных требований разработчики языка знать не могут. А именно эти требования делают к примеру питон неприменимым к подавляющему большинству задач индустрии. Все это вопросы библиотечных средств. Именно таким способом - все что можно реализовать библиотечно выносить в библиотеки и достигается универсальность и гибкость подстройки языка под задачу.
Т.е. абстрагироваться от задачи не получится. Можно даже не пытаться. Единственное что можно в этом плане сделать - построить библиотечные средства имеющие средства подстройки под конкретные требования конкретной задачи. В плюсах это возможно. В питоне нет.

Добавлено через 18 минут

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

Вы опять лекарство принять забыли?

Сообщение от COKPOWEHEU Потому что данные, будучи один раз записаны, потом не меняются

И как это мешает тому куда они записаны быть ячейками памяти?

Сообщение от COKPOWEHEU Вместо них вводятся другие сущности.

И каким образом это отменяет тот факт что необходимо найти для них свободное место? Т.е. взять новые листики в случае если считаем на бамашке, и переодичекси выкидывть листики с промежуточными данными которые уже не нужны из стопки дабы не раздавить стол, что абсолютно ничем не отличается от ОЗУ на перфоленте/перфокарте? ( да кстати именно для этого - переписать на новую перфоленту с исчерпанной только нужные в дальнейшем данные, и родился в 40-х предок GC).
А в случае на доске - то тоже нужно найти ненужные уже промежуточные данные которые можно затереть. И каким образом то что туда запишут другие данные помешает этому месту быть ячейками памяти? И чем это отличается от ОЗУ многократной записи? К примеру магнитной ленты, (для которой в 50-х и родился GC).

Сообщение от COKPOWEHEU . Новые имена переменных, если говорить про математику.

Да вот собственно говоря именно так и работает ФП. И товарищ Черч в свое время кучу сил положил на то чтобы математически доказать возможность построения тюринг-полного вычислителя на ленте с однократной записью.
Мало того - именно так и работает вычисление элементарных выражений в любом высокоуровневом ЯП - тут как раз та ниша в которой ФП очень даже на своем месте.
Так что мой вам дружеский совет - освойте хотя бы азы специальности для начала. А то у вас в голове реально полная каша.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Нет. Но это не важно, поскольку, как уже было сказано, возможность накручивания абстракций ни на что не влияет.

Вы же там что то про высокоуровневые абстракции лепетали? А теперь возможность их создания и использования типа ни на что не влияет? Что как бред повторять не понимая его сути так вы типа молодец. А как оказывается что важна возможность создания и использования абстракций - так сливаетесь типа абстракции не важны?

Добавлено через 15 минут

Сообщение от COKPOWEHEU то есть язык, не пригодный для низкоуровневого программирования, быть высокоуровневым не может". Отличная логика!

Еще раз для самых безграмотных COKPOWEHEU, - системное программировние != низкоуровневое.
Низкоуровневое программирование - это работа напрямую с "железом" - т.е. непосредственная запись/чтение в порты ввода-вывода и регистры переферийных устройств подключенных к системной шине. И это мизерная доля системного программирования. Низкоуровневое программирование в условиях современных осей вообще возможно только для драйверов нулевого кольца, и даже для них является мизерной долей их работы. Тут принцип тот же самый - то что меняется при смене девайса - к примеру алгоритм получения буферов из сетевой карты - это низкоуровневое программирование.
А к примеру реализация протокола TCP/IP сортирующего пакеты и проверяющего полноту доставки и т.д. дела от девайса не зависит, а соответственно уже есть высокоуровневое программирование. Хотя точно так же системное.
Системное программирование -это в первую очередь создание библиотек. При этом в реалиях современной разработки, особенно по ООП-методологии проектирования, вся разработка ведется путем создания/расширения специализированных библиотек. Прикладная же софтина получается путем декларативной сборки модели из сущностей описываемых классами созданных библиотек. Т.е. язык не пригодный для создания библиотек для самого себя к современной промышленной разработке софта не пригоден от слова совсем.

Добавлено через 27 минут

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

Эт вы пиндостанским евангелистам шарпнутых жабопитонов предьявляйте.
Хотя их то понять можно - удар по национальной гордости у них был жесточайший. Они то всегда были наиболее компутеризированной нацией и в плане языкостроения таки были до этого впереди планеты всей. Все таки в предыдущих поколениях языков Фортран и потом С были неоспоримыми лидерами. У Европы с этим все было в общем то грустно. Убивцу Фортрана Алгол рожала-рожала и фактически родила через несколько лет после его похорон. Да и из Паскаля конкурент С не получился от слова совсем. А тут аж три сразу языка нового поколения от европейцев и все успешные а один даже по заказу Пентагона. И свой аж только через 10 лет слепить смоги. И такое УГ оказалось что из того направления куда его автор планировал погнали его сцаными тряпками и даже чуть не рассреляли с горяча - думали диверсант какой.
А тут еще и такая заковырка случилася что квалифицированные спецы в закромах Родины то закончились. А голодный рынок он все схавает, только пообещай слепому глаза а кастрату яйца. И пошло поехало бред про "сверхвысокоуровневые " бред про "абстракции" - вобщем про "убер-тулз" который типа позволит быдлокодерам без малейших познаний в специальности типа COKPOWEHEU, софт клепать типа быстрее круче и надежнее чем квалифицированные разрабы. И таки схавали - а деваться то этим шарашкиным конторам некуда было - квалифицированный народ то купить у них денег не хватало. Их то банкротится 80% в первый год а из оставшихся еще 80% во второй. А потом крики про популярность пошли - еще бы быдлокодеров для решения 1% задач по разравниванию ввода-вывода понадобилось то в 10 раз больше чем спецов для решения остальных 99% - обработки данных. А потом Майкрософту идея понравилась и себе так же сливки на говне собирать захотелась. А потом IBM. И т.д. И отак это все больше и больше маркетинговыми мифами и обрастает которые ничего общего с реальностью не имеют. В реальности вся это война жабопитонашарпов про меж собой - не более чем битва за крохи с барского стола контор слившихся в плане разработки средств разрвботки еще в 90-х.
А к примеру тот же Борланд жаба-билдер выкинул из своей линейки как неюзабельный еще в 2000-ом. И C# билдер релизить не захотел - настолько ущербным получился в следствие ущербности и не пригодности к созданию высокоуровневых абстракций шарпа. Т.е. к реальным то делам эти ошибки природы вообще никаким боком не притулили. Так и барахтаются на самом дне в странах третьего мира.
А все серьезные дела делают таки квалифицированные спецы таки на универсальных языках. Потому что суть программирования - это создание высокоуровневых абстракций. Именно поэтому плюсы и вытеснили практически все остальное в профессиональной разработке - именно в плане средств построения и использования высокоуровневых абстракций им равных нет.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Нет, вы талдычите какую-то чушь про то, что указатель это и есть тензор

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

0

Сообщение от Fulcrum_013 Ну покажи где у GC средства автоматики

Я сейчас зашёл в раздел плюсы для начинающих, и, просмотрев немного тем нашёл что искал для иллюстрации Как решать проблему со вводами C++ . Смотрим на код из СП. И такого там навалом.
По этому и обучают "ан масс" на языках с GC. Думаете, начинающего можно сразу приучать к смартпонтерам не объяснив что это такое и как работает? Вообще то я ни разу не преподавал, но, подозреваю, что с этим проблемы, иначе бы кто то бы так и преподавал - сразу плюсы со смартпоинтерами. Начинающие - они такие начинающие. Как мне сказала дочка знакомого, которая училась на постановщика задач в экономической сфере (и работает теперь секретаршей), "так то я си шарп знаю, только, вот, массивы у меня как то не очень". А вы говорите смартпоинтеры.

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

0

Сообщение от Fulcrum_013 Указатель есть тензор

Тогда что во что он преобразовывает?

Сообщение от Fulcrum_013 его суть от смены СК не меняется

Суть любого вектора от смены СК не меняется - и что?

Сообщение от Fulcrum_013 Т.е. к примеру для индекса I преобразование в глобальное адресное пространство осуществляется умножением на метрический тензор адресного пространства определяемый массивом a. т.е. правило его преобразования в конечном итоге получается (a+i)

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

Сообщение от Fulcrum_013 Именно работа с типами встроенными в язык - и есть небезопасная низкоуровневая каша в коде.

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

Сообщение от Fulcrum_013 К примеру если вы работаете с массивами то количестов элементов должен быть один тип, емкость другой, а Id вообще третий.

Такой дурацкий подход привел бы к усложнению около O(N²). Естественно, что кроме некоторых учебных задач он не встречается. Число есть число, будь то номер элемента или их количество.

Сообщение от Fulcrum_013 забота языка Забота библиотек.

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

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

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

Сообщение от Fulcrum_013 А у С С++ паскаля и прочих нативных языков размер не зависит от платформы - он задан в стандарте языка

Ну и какой размер устанавливает стандарт языка С++ для целого числа?
Между прочим, в отличие от С++, стандарт Паскаля таки дает на это четкий ответ, что однако, не делает его более высокоуровневым, потому что этот размер все равно привязан к платформе. В высокоуровневых же языках число это именно число, в математическом смысле.

Сообщение от Fulcrum_013 И нет, возможность накрутить абстракции на это не влияет. Влияет и еще как.

Поскольку мы говорим о языке, а не о библиотеках - естественно, не влияет.

Сообщение от Fulcrum_013 Если нужна длинная арифметика то есть мульен вариантов как ее реализовать

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

Сообщение от Fulcrum_013 Т.е. абстрагироваться от задачи не получится. Можно даже не пытаться.

Решая задачу не получится от нее абстрагироваться? Вас опять Капитан покусал?
Естественно, решая задачу, надо решать задачу. Задачу, а не особенности конкретной архитектуры! При решении задачи глубоко безразлично в каком именно формате хранятся строки, выровнены ли данные по ячейкам, конечен ли размер машинного слова и сколько в нем байтов.

Сообщение от Fulcrum_013 Вы опять лекарство принять забыли?

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

Сообщение от Fulcrum_013 И как это мешает тому куда они записаны быть ячейками памяти?

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

Сообщение от Fulcrum_013 Да вот собственно говоря именно так и работает ФП.

Ого, вы знаете такой термин как ФП! Очевидно, вы и его считаете тупиковой ветвью по сравнению с божественными плюсиками.

Сообщение от Fulcrum_013 Вы же там что то про высокоуровневые абстракции лепетали? А теперь возможность их создания и использования типа ни на что не влияет? Что как бред повторять не понимая его сути так вы типа молодец. А как оказывается что важна возможность создания и использования абстракций - так сливаетесь типа абстракции не важны?

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

Сообщение от Fulcrum_013 системное программировние != низкоуровневое.

Но низкоуровневое программирование составляет подавляющую часть системного. Дальше что?

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

Читать весь этот бред мне лень. Допустим, вы нашли теорию заговора, молодец. И что? Объективных данных это не меняет. Как занимал С++ свою нишу, так и занимает. Ни в системном программировании, ни в скриптостроении его почти нет. К чему была ваша портянка?

Сообщение от Fulcrum_013 Нет, вы талдычите какую-то чушь про то, что указатель это и есть тензор Это есть факт.

Ок, вы сами признали, что то, что вы талдычите чушь - факт.

Сообщение от Fulcrum_013 Потому что не понимаете того что такое тензор от слова совсем.

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

Добавлено через 6 минут

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

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

0

Сообщение от COKPOWEHEU Но вот давать школьникам начальные навыки программирования на языке высокого уровня однозначно лучше, чем на низкоуровневом.

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

Сообщение от COKPOWEHEU будут ядра и драйвера писать, тогда волей-неволей выучат Си с ассемблером.

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

0

Сообщение от COKPOWEHEU При решении задачи глубоко безразлично в каком именно формате хранятся строки,

А вот это уже зависит от задачи. У разных задач разные требования в этих вопросах. Вытекают из требований к надежности системы. В системах повышенной надежности перераспределение динамической памяти недопустимо. В задачах офисного класса перераспределение памяти наше все.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Ну вот, а чего тогда дурачком прикидывались!

ДАк вам это уже 5-ю страницу толдычат. Указатель есть тензор. А соответсвенно и индекс и ассоциативный ключ и вообще любое представление адреса ячейки ничем от сырого указателя не отличаются, окромя того что арифметика у указателя более безопасная.

Добавлено через 5 минут

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

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

Добавлено через 20 минут

Сообщение от COKPOWEHEU Такой дурацкий подход привел бы к усложнению около O(N2).

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

Сообщение от COKPOWEHEU Естественно, что кроме некоторых учебных задач он не встречается.

Используется повсеместно кроме разве что учебных задач самого начального уровня.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Число есть число, будь то номер элемента или их количество.

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Поскольку мы говорим о языке,

Возможность создавать и использовать абстракции у С++ суть языка. В питоне же средств создания абстракций нет от слова совсем. Библиотеки это уже наборы реализованных абстракций. Причем сменные наборы для более точной подстойки под задачу.
Если говорим не о библиотеках а только о ядре - то никаких абстракций в питоне нет вообще и взяться им не откуда. Все искоробочные абстрактные объекты у него точно так же живут в искоробочных библиотеках, только вот к написанию оных библиотек питон не пригоден от слова совсем.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Повторяю: программист должен решить поставленную задачу,

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Ого, вы знаете такой термин как ФП! Очевидно, вы и его считаете тупиковой ветвью по сравнению с божественными плюсиками.

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Да тут даже понять что же вы имеете в виду под тензором проблема.

Ну учится надо было по специальности а не штаны просиживать. Сразу бы понимали. А то ни того что такое тензор не знаете ни того что такое указатель. И даже не понимаете что и то и другое - абстракции.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Но этот вопрос программиста волновать не должен.

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

Добавлено через 5 минут

Сообщение от COKPOWEHEU Это другая абстракция, другой подход.

Тот же самый подход и та же абстракция. А оная пачка бумашек называется по англицки staсk.

Добавлено через 2 минуты

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

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

Добавлено через 7 минут

Сообщение от COKPOWEHEU А вплетение в алгоритм задачи еще и особенностей выделения памяти - однозначно признак говнокода.

Ну вот такой говнокод с особенностями выделения у вас будет на С или питоне.
В плюсах же алгоритмы работы с памятью будут сконцентрированы в одной библиотеке. В остальных же местах для некоторых структур данных будет декларативно (т.е. аргументом шаблона при объявлении структуры) указываться аллокатор ( т.е. просто другой алгоритм из библиотеки) в случае если заданный для них по дефолту не подходит. Тотчно так же с средствами автоматики. Или средствами длинной арифметики или вообще чем угодно.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Именно поэтому Питон получил такую популярность: высокоуровневый язык, в котором уже реализованы все основные абстракции

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

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Но низкоуровневое программирование составляет подавляющую часть системного.

Не составляет. Это мизерная доля системного программирования. Еще раз для самых безграмотных - системное программирование - это программирование не привязанное к конкретной предметной области, а не работа "с железом".

Добавлено через 13 минут

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

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

Добавлено через 6 минут

Сообщение от COKPOWEHEU Вы, наверное, опять берете за эталон С++, в котором, в силу низкоуровневости, встроенные типы плохо подходят для не-системных задач.

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Зависит от задачи. Если речь о низкоуровневом коде, то приоритет в эффективности - берем машинные типы данных. Если в универсальности - абстрактные.

Или берем С++ и имеем и одно и другое сразу.

Добавлено через 40 секунд

Сообщение от COKPOWEHEU Видимо, я слишком быстро говорю, и для вас поток новой информации сливается в "лепет".

вы не говорите. вы бредите.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Объективных данных это не меняет.

Что вы называете объективными данными?

Добавлено через 12 минут

Сообщение от COKPOWEHEU Суть любого вектора от смены СК не меняется - и что?

Ну вот именно. Никакой принципиальной разницы между тем что использовать - сырой указатель или индекс массива или ассоциативный ключ нет. Одни и те же ошибки приведут к одним и тем же последствиям. При этом арифметика указателей безопаснее чем арифметика индексов. Банально потому что не удастся сложить два указателя и получить чушь, как это можно сделать с индексами. Т.е. если указатели считать unsafe то индексы массивов и ассоциативные ключи нужно делать unsafe в квадрате.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Да тут даже понять что же вы имеете в виду под тензором проблема.

Потому что вы не понимаете что такое тензор.

Добавлено через 10 минут

Сообщение от COKPOWEHEU Такой дурацкий подход привел бы к усложнению около O(N2).

Дурацкий подход - это не определять алгебру над сущностями. Соблюдение ее правил все равно придется обеспечить.
А соответственно определив их один раз описанием соответсвующих типов и поераторов перекладываем во всем остальном коде слежение за их соблюдением на машину.
Не делая этого вы банально заставляете программиста следить за соблюдением правил алгебры над сущностми во всем коде. Т.е. даже если алгебра потребовала прегрузить O(N^2) операторов, то не перегрузить их будет соответсвовать O( exp(N)).
В реалиях же плюсов даже O(N^2) сведется приблизительно к O(N) за счет того что будут указаны только принципы генерации операторов, сами же операторы сгенерирует компилятор.

Добавлено через 5 минут
Добавлено через 10 минут

Сообщение от COKPOWEHEU Такой дурацкий подход привел бы к усложнению около O(N2).

Дурацкий подход - это не определять алгебру над сущностями. Соблюдение ее правил все равно придется обеспечить.
А соответственно определив их один раз описанием соответсвующих типов и операторов перекладываем во всем остальном коде слежение за их соблюдением на машину.
Не делая этого вы банально заставляете программиста следить за соблюдением правил алгебры над сущностми во всем коде. Т.е. даже если алгебра потребовала прегрузить O(N^2) операторов, то не перегрузить их будет соответсвовать O( exp(N)).
В реалиях же плюсов даже O(N^2) сведется приблизительно к O(N) за счет того что будут указаны только принципы генерации операторов, сами же операторы сгенерирует компилятор.
Вот это и есть сверхвысокоуровневые абстракции, а не тот бред который вы несете про типа абстрактные библиотечные средства. Мало того то что есть в этих средствах в этих ваших "уберязыках" существенно уступает по своим возможностям и уровню реализуемых абстракций тому что есть в этом плане для плюсов.
Еще раз для самых одаренных - доступность абстракций определяется в первую очередь возможностями ядра языка в их создании и использовании. Без возможности их создания нельзя и реализовать библиотеки оных абстракций. Без возможности их использования/параметрической конкретизации невозможно и использовать библиотеки абстракций, созданные на языках где средства создания абстракций есть.

0

Сообщение от Curry Нет такого деления - более высокоуровневый язык и менее.

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

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

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

Сообщение от Fulcrum_013 ДАк вам это уже 5-ю страницу толдычат. Указатель есть тензор.

Понятно. То есть прочитать хотя бы свою ссылку вы так и не осилили.

Сообщение от Fulcrum_013 А при чем здесь вообще архитектура проца а тем более PDP?

При том что это модель машины, на которой работают С, С++, Паскаль и прочие. В ней не учитываются современные тенденции процессоростроения вроде конвейера, предсказания переходов, частично параллельных или вообще параллельных операций.

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

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

Сообщение от Fulcrum_013 Возможность создавать и использовать абстракции у С++ суть языка.

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

Сообщение от Fulcrum_013 Задача выдвигает свои конкретные требования как к форматам данных так и к способам работы с памятью и т.д. и т.п.

В системном программировании, пожалуй, да. Там приходится за этим следить. Ну так и высокоуровневые языки там не используются.

Сообщение от Fulcrum_013 Это другая абстракция, другой подход. Тот же самый подход и та же абстракция.

Научитесь цитировать по-человечески. Пока что ваше высказывание выглядит как "сам дурак". Впрочем, зная вас, оно и по существу не сильно конструктивнее.

Сообщение от Fulcrum_013 Ну учится надо было по специальности а не штаны просиживать. Сразу бы понимали.

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

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

Согласен, если самолет будет управляться вашим софтом, то поможет разве что молитва.
Если же присутствует грамотный процесс разработки с разделением по уровням абстракции, модульностью и независимым тестированием, то есть хотя бы вероятность что он полетит так как надо. Но вам это не грозит, потому что "грамотный процесс разработки" предполагает в том числе применение инструмента, заточенного под задачу, а не С++ во все поля.
Но не расстраивайтесь, возможность попасть в небо есть и у вас: купите запчасти для радиоуправляемого самолета или квадрокоптера, напишите прошивку (модель софта реального самолета) и посмотрите что получится. Причем рекомендую отнестись к этому совету серьезно. Даже небольшой опыт работы в смежной области здорово помогает и в основной.

Сообщение от Fulcrum_013 В самом питоне вообще никакие абстракции не реализованы

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

Сообщение от Fulcrum_013 Ну правильно. Берем плюсы. Берем библиотеку обеспечивающую требуемую подстройку. Один раз задаем нужные нам параметры реализации строк и т.д. и больше об этом не думаем. Т.е. решаем задачу в общем.

Ну то есть берем С++ и допиливаем до чего-то похожего на ЯВУ. А можно сразу взять ЯВУ.

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

Поэтому при грамотном проектировании характеристики описываются в документации. Независимо от языка.

Сообщение от Fulcrum_013 Зависит от задачи. Если речь о низкоуровневом коде, то приоритет в эффективности - берем машинные типы данных. Если в универсальности - абстрактные. Или берем С++ и имеем и одно и другое сразу.

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

Сообщение от Fulcrum_013 вы не говорите. вы бредите.

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

Сообщение от Fulcrum_013 Что вы называете объективными данными?

По определению - данные, не зависящие от наблюдателя. Или у вас опять какое-то свое "определение", отличное от общепринятого?
Например, ищем любую статистику популярности языков программирования и видим, что язык С++ не то что недостижим для остальных, но даже не на первом месте. Ищем любую другую статистику - видим то же самое. И в третьей, и в четвертой. Вот это - объективные данные.
А те "проценты", которые приводите вы - субъективны, потому что никто кроме вас о них не знает.

Сообщение от Fulcrum_013 При этом арифметика указателей безопаснее чем арифметика индексов. Банально потому что не удастся сложить два указателя и получить чушь, как это можно сделать с индексами.

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

Сообщение от Fulcrum_013 Потому что вы не понимаете что такое тензор.

Так я ж с этого и начал, что я не понимаю вашего определения тензора. Обычное понимаю, ваше альтернативное - нет.

Сообщение от Fulcrum_013 то не перегрузить их будет соответсвовать O( exp(N)).

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

Сообщение от Fulcrum_013 Еще раз для самых одаренных - доступность абстракций определяется в первую очередь возможностями ядра языка в их создании и использовании. Без возможности их создания нельзя и реализовать библиотеки оных абстракций.

Еще раз для самых одаренных - это реализуется в любом языке.
---
Ладно, про тензор вы не знаете и знать не хотите. Учитывая, что ни цитирование определений, ни реальные примеры на вас не действует, оставим эту тему, лучше вернемся к более программерским вещам.
Вы так и не привели размер актуальной винды, пригодной для повседневного использования не-специалистами.
Вы так и не сформулировали почему в системной (низкоуровневой) разработке вроде ядра ОС, драйверов или микроконтроллеров, почти не используется С++.

0

Сообщение от COKPOWEHEU Чем меньше язык привязан к конкретной машине, тем выше уровень языка.

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

Добавлено через 7 минут

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

А никто и не говорил что ассемблер знать не нужно. Но как бы и программирование на ассемблере не обязательно низкоуровневое. Все программирование на асме кроме непосредственно обращения к портам ввода-ваода переферийных устройств точно так же высокоуровневое. Вообще всыско/низко уровневость программирования и высоко/низкоуровневость языка на котором оно осуществляется - ортогональные понятия. Именно поэтому делать что то кроме обращения к портам ввода-вывода на низкоуровневых языках и не имеет смысла. А соответственно и системное программирование производится в основном на высокоуровневых языках.
При этом еще раз - работа с железом и даже ядро оси - это капля в океане системного программирования.

Добавлено через 4 минуты

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

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Ну то есть берем С++ и допиливаем до чего-то похожего на ЯВУ.

Т.е. берем ЯВУ С++ и решаем задачу. А то что вы называете какими то мифическими ЯВУ годных средств для решения подавляющего большинства задач как не дают искаропки, так и не позволяют их создать.

Добавлено через 9 минут

Сообщение от COKPOWEHEU Поэтому при грамотном проектировании характеристики описываются в документации. Независимо от языка.

И что вам толку от того что они описаны но для конкретной задачи не подходят? Будете другой язык искать? В нем тоже что то не подойдет. И закончится это изобретением нового говноязыка.
В плюсах же, точно так же как в других универсальных языках, просто библиотеки меняются на подходящие. В случае если какой то подходящей еще не существует она на плюсах же и пишется. Дописать нужную библиотеку это быстрее и проще чем изобрести очередной одноразовый язык. Т.е. предоставляемый универсальными языками уровень абстракции на порядки выше чем у этих куцых манаджед обрубков мифического "общего назначения".
Еще раз - по факту концепцию специализированных языков убил еще фортран. Последним гвоздем в гроб этой концепции стали процедурные С и паскаль, которые позволили использовать библиотечные средства способом семантически неотличимым от добавления их в ядро. Современные же универсальные языки пошли еще дальше - перегрузка операторов и т.д. делает использование библиотечных типов не только семантически но и синтаксически неотличимым от использования встроенных в ядро языка. А по сему ваши эти "общего назначения" - ни специализированные, ни универсальные, а какие то ущербные неведомы зверушки.

Добавлено через 12 минут

Сообщение от COKPOWEHEU ..но медленнее, неудобнее и дольше. Уже не раз говорил: если бы С++ превосходил все остальные языки по всем параметрами, он бы их вытеснил.

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

Добавлено через 8 минут

Сообщение от COKPOWEHEU Например, ищем любую статистику популярности языков программирования и видим,

С каких пор статистика популярности стала объективными данными? Она абсолютно не отражает ни то какой процент задач на каком языке решается, ни сложности решаемых задач, ни степени их важности. ни доли в обработке информации.
Точно так же объективно то, что 90% разработчиков в индустрии не квалифицированные, и суммарно на всех этих "популярных" языках решают около 1% задач.
Т.е. "популярность" тут показатель исключительно низкой продуктивности в решении задач.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Итак, откуда в вашей оценке сложности взялась именно экспонента, а не полином, логарифм или факториал?

При разработке растет как и количество типов над которыми нужно обеспечить соблюдение правил алгебры, так и объем кода для которого это надо сделать. А соответсвенно, поскольку в этом плане необходимо согласовывать зависимоси между разными строками, имеем сложность пропорицональную количеству m строк кода в степени n^2 правил.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Учитывая, что ни цитирование определений, ни реальные примеры на вас не действует, оставим эту тему, лучше вернемся к более программерским вещам.

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

Добавлено через 2 минуты

Сообщение от COKPOWEHEU Еще раз для самых одаренных - это реализуется в любом языке.

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

0

Сообщение от COKPOWEHEU Чем меньше язык привязан к конкретной машине, тем выше уровень языка.

С++ не привязан к конкретной машине. В стандартах языка ничего нет про конкретную архитектуру или ОС.
Как и в стандартах всех ЯВУ (ну, может, кроме каких то специализированных).

Сообщение от COKPOWEHEU Это просто классификация для удобства.

Только если ваша личная классификация, но не общепринятая. Да и дело не в названии.

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

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

0