ЛОР, помоги выбрать ЯП для обучения

не знать элементарной высшей математики?

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

«аналитические методы решения» не дают самих численных решений. они дают формулы для из получения.

Вот кстати да. Именно поэтому сейчас чаще применяются именно что численные методы. Они проще в употреблении хотя и не дают «абсолютно точных» результатов. Но в инженерной практике «абсолютная» точность и не нужна. Нужна достаточная.

не все уравнения решаются аналитически.

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

К примеру при объяснении пути конец от середины улицы также невозможно отличить по контексту

Середина (улицы, комнаты) будет 中间 (zhōngjiān) = «середина пространства».

Конец улицы скорее назовут 尽头 (jìntóu) = «край, тупик».

В письменном тексте, разумеется, свободно будут использовать омонимы, так как иероглифы выглядят по-разному.

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

Там аннотация есть.

То есть у них прослушивание аудиокниги невозможно/сильно затруднено без предварительного прочтения письменной аннотации? А как же тогда радиовещание? Программу передач заранее читать?

Вот восприятие театральных пьес чем-то похоже на восприятие китайского. Чтобы понять балет «Лебединое озеро» надо сначала прочитать сюжет. Иначе даже не угадать, кто персонажи.

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

Проблема возникает только если читать письменный текст вслух.

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

приходится переводить или дополнять

Так это же должно приводить к существенному искажению информации?

https://www.tuhs.org/cgi-bin/utree.pl?file=V2/lib/printf.c

рекурся мало кому нужна

а ещё меньшему числу понятна

Ошибка будет

Это компиляторный хак. Допустим я хочу реализовать «по уму» format из ЛИСПа про который компилятор крестов ничего не знает. Мои действия?

А для С++ есть библиотеки с проверками

Показывай.

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

Многовато приседаний. Кроме того, числа в строки это боксинг на коленке. Т.е. вместо int ты получаешь Integer, который Object и умеет себя печатать. Неоптимально, как и любой боксинг.

в основе всего лежит исчисление бесконечно малых и прочие поиски предела последовательностей

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

На каждый конечный положительный эпсилон найдётся своя дельта

∀ϵ>0,∃δ>0| 0<|x−c|<δ⟶|f(x)−L|<ϵ

это определение непрерывности?!

Это компиляторный хак.

Ну так тут типов нету.

А для С++ есть библиотеки с проверками

Показывай.

std::format

Ну так тут типов нету

Так и запишем: по уму – это когда нету типов.

Хватит бредить, ты сам про printf написал, я тебе ответил что там типов нету, два раза, тебе не хватает двух раз что бы понять? Тема printf со статикой вообще очень слабо связана, однозначно его подход из С это не «по уму».

это определение непрерывности?!

Если f(c) = L

Думаю там нового кода намного больше пишется на Python и С++.

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

Похоже чтобы понять в чем разница - надо знать китайский.

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

А сейчас еще аудиокниги есть. Или у китайцев их нет?

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

Тот или иной смысл они обретают именно что в голове читающего.

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

То же самое можно объяснить менее колхозно, с применением зигохистоморфных-пре-про-морфизмов и комонад, которые копприменяют копрограммы ко-ко-компилятора, но: а) я так не умею; б) кто этот теоркат уже понял, тот и так всё знает, ему ничего объяснять не надо.

Чтобы понять балет «Лебединое озеро» надо сначала прочитать сюжет. Иначе даже не угадать, кто персонажи.

Зависит от насмотренности. Полностью сюжет, понятно, не восстановить, уж имена точно не получится, но:

а) балеты того периода обладают определённой формальной структурой;

б) есть стандартные амплуа и система выражения эмоций/отношений персонажей;

в) балет нужно смотреть, там же всё наглядно показано.

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

Такая простота что куча народа даже вобщем-то умеющая программировать - ее не понимает.

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

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

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

Вот кстати да. Именно поэтому сейчас чаще применяются именно что численные методы.

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

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

Это в какой-то мере и отвечает на вопрос, зачем нужны рекурсивные алгоритмы.

Ну из этого списка, реально мёртвым можно назвать только перл.

Однако apt rdepends покажет Perl скорее всего на средней системе, в независимости от того десктоп это или сервер, а вот Ruby сомнительно что там будет.

делфи стандарт для написания оконного софта в корпах

Это уже давно C#, а на самом деле React.

фортран как был на суперкомпах, так там и остался

Нового почти не пишут, непонятно тогда чем он живее Perl.

малословный

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

ОПЕРАТОР_НАЧАЛО_УСЛОВИЯ_В_ПИТОНЕ = 0
ОПЕРАТОР_КОНЕЦ_УСЛОВИЯ_В_ПИТОНЕ = 0

if (True):
    ОПЕРАТОР_НАЧАЛО_УСЛОВИЯ_В_ПИТОНЕ
    print("Hello world")
    ОПЕРАТОР_КОНЕЦ_УСЛОВИЯ_В_ПИТОНЕ

Как операторный шум в программе дает понятности? Никак, это и к Ada применимо. Дополнительное описание ограничений, или особые операторы для ограничения вариантов их использования, такие как beginIf, endIf мне понятны. А зачем раздувать одни из часто используемых операторов? COBOL это вообще вершина понятности?

Потому что не слишком высокоуровневый

Кто более высокоуровневый?

Самое то это Паскаль! Более того он ни такой уж и мёртвый, до сих пор существуют программы которые живут и поддерживаются и написаны на Delphi (а это так сказать финальная версия развития Паскаля)

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

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

Веб это будущее и настоящее, так что ориентация на веб явно более правильная чем на TurboPascal в MS-DOS который есть прошлое в любом виде.

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

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

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

Вот если говорить про OpenSource, где часто один проект ведет один человек, то все верно, там программист сам определяет каким должно быть его ПО.

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

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

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

Получается, что и про бесконечный цикл нам наврали.

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

Но это не мешает мне иметь в голове концепцию бесконечности.

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

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

А вот «не имея способа построить» - это уже философия. «Можем-ли мы это построить, не можем-ли мы это построить, бла-бла, ультрафинитизм, та-та, физическая непрерывность пространства, бла-бла»

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

Если брать пьесы Гоголя или Чехова, то они достаточно бытовые, чтобы китайцу их можно было понять на слух.

Если же произведение незнакомое с текстом типа «Пока Бирнамский лес не выйдет в бой На Дунсинанский холм.» или как у Грибоедова, то без текста вряд ли поймут. Будет очередная красавица Икуку.

А на нем и через полвека пишут в научной среде. Почему-то он нравится математикам и физикам.

Чел забыл, что Фортран именно объявили устаревшим систы, а не он вышел из употребления естественно. Систы бросили лозунг «перепишем все фортран-проги на Си», но пог оказалось сильно больше, чем энтузиазма, а назначение Фортрана мало пересекалось с назначением Си.

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

Чел забыл, что Фортран именно объявили устаревшим систы

Кто то из авторов Basic.

Систы бросили лозунг «перепишем все фортран-проги на Си»

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

Фортран хорош для ...

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

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

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

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

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

Я проснулся с ужасной мыслью!

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

Получается, что и про бесконечный цикл нам наврали.

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

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

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

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

Есть такой миф, да.

Так же фортран нужен тем кто под видеокарты разрабатывает софт

Все библиотеки для CUDA это C/C++, тоже самое и у Intel. Fortran я так понимаю больше для легаси. Полезно засунуть туда легаси на фортране и получить ускорение.

А вот «не имея способа построить» - это уже философия. «Можем-ли мы это построить, не можем-ли мы это построить, бла-бла, ультрафинитизм, та-та, физическая непрерывность пространства, бла-бла»

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

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

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

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

Странно. Фортрановские алгоритмы и так уже вылизаны, дальше некуда.

Интеловские компиляторы выделялись оптимизациями под вектора (SSE и прочее) из циклов. Когда в GCC и LLVM добавили аналогичные алгоритмы, интеловский забросили.

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

Странно. Фортрановские алгоритмы и так уже вылизаны, дальше некуда.

Это фортран дает такие бафы? %) Уверен много кода на фортране это ужасный if-goto-код оптимизированный под запуск с 2 битами памяти, противоположность тому что надо сейчас.

Может когда то их «вылизали», но те архитектуры давно умерли, а нынешние не узнать. А код все такой же. Явно не от того что с первого раза хорошо написали. Легаси.

Интеловские компиляторы выделялись оптимизациями под вектора

Я смотрел только современные сравнения, где то после 2015. Не удивлюсь если Intelу удавалось лучше векторизовывать код как раз заменой if-goto мешанины на более простые циклы.

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

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

Определять использование, и типы использования умеет даже fasm

В смысле, fasm сумеет преобразовать

s = malloc(strlen(s1) + strlen(s2) + strlen(s3) + 1);
s[0] = 0;
strcat(s, s1);
strcat(s, s2);
strcat(s, s3);

в

_n1 = strlen(s1);
_n2 = strlen(s2);
_n3 = strlen(s3);
s = malloc(_n1 + _n2 + _n3 + 1);
memcpy(s, s1, _n1);
_p = s1 + _n1;
memcpy(_p, s2, _n2);
_p += _n2;
memcpy(_p, s3, _n3);
s[_p + _n3] = 0;

?

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

у вас даже нет конструктивного алгоритма установления равенства двух действительных

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

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

Да и хрен с ними, с дейтсвительными числами. Целые гораздо лучше! И удобнее. И никаких проблем с округлением.

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

это не должно быть сильно затратно если все условия уже известны?

Если вручную прописывать все случаи замены strcat на memcpy, то да. Если заставить компилятор залазить в исходники функций и догадываться, что memcpy делает то же самое, что strcat, если известен адрес конца, а strlen вычисляет адрес конца, то затратно.