Pull to refresh

Comments 764

Вся компьютерная индустрия, начиная со второго поколения компьютеров — бесконечная попытка забыть тот ужас, который нас ждёт с initial orders и осцилографом. Попытка забыть этот ужас порождает новый ужас (обычно меньшего размера), и идёт ещё одна попытка забыть ужас.

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

… Проблема начинается в тот момент, когда нижележащий уровень перестаёт прятать сложность и оно взрывается как пружина. Обычно люди просто стараются увернуться (включить/выключить, попробовать ещё раз), а не выяснять что именно там случилось.
Я хорошо помню, как году в 2009 смотрел на Rails.
Когда смотришь на готовый проект (что пример, что просто хороший чужой код) и всё очевидно. Начинаешь делать что-то сам — и упираешься в дикие ограничения, при решении которых натыкаешься либо на готовые сниппеты (магия!), либо городишь дикий код.
Потом начинаешь оборачивать дикий код в магию.

Тогда я это объяснил себе это спецификой декларативных языков, но в целом это свойственно для любой сложной системы — а код сейчас действительно сложный.
UFO just landed and posted this here
В декларативщине обычно более заметно из-за того, что мало в какой декларативщине можно прыгнуть на нижележащий уровень и доработать там напильником. Но да, это в любой сложной системе так.
Да, это именно специфика декларативных языков. Магия «мы описываем проблемму и оно как-то само нам говорит результат» не бесплатна и за ней стоит огромная «подводная» часть.

Замените рельсу на SQL — ничего не изменилось.

Рекорд, который я не знаю, будет ли побит когда-либо установил Пролог.

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

Но при этом достаточно в первой же нетривиальной программе из любого учебника по Прологу поменять две строки местами (а это, как понятно, «информацию о предметной области» не меняет) — и привет: программа зациклится и упадёт, сожрав предварительно всю память.

Блеск!
Вроде бы должно быть каждому понятно, что из описания нетривиальной задачи её эффективное решение не следует. Или, например, что связки И/ИЛИ на практике не коммутативны.
Пробел пропустил. Имеется в виду «не тривиальная» задача, а не «нетривиальная».

Как правило первая не тривиальная задача в учебниках — это набор фактов из Библии (пролог ещё до эпохи толерантности появился, там на Библию ещё можно ссылаться). Набор фактов вида «Исаак родил Иакова» и правила вывода (два):
1. Если A родитель B, то A — предок B.
2. Если A родитель B, а B — предок C, то A — предок C.
Так вот если эти правила поменять местами, то программа «рассыплется».

Восхитительная «декларативность».
Подождите, но тут всё достаточно логично (как для человека, который никогда не видел пролог). В правиле №2 должно быть известно что такое «предок», т.к. это нужно для интерпретации части условия («а B — предок C»). Или пролог даёт какие-то гарантии того, что порядок задания правил не важен?
Оба правила вместе описывают что такое предок.

Но с точки зрения человека последовательность этих правил — неважна. Такое определение: «предок твоего папы — это твой предок… ну и твой папа — тоже твой предок» — человек поймёт.

А с точки зрения Пролога — важна. «Предок твоего папы — это твой предок… ну и твой папа — тоже твой предок» — Пролог не поймёт. Зациклится. Где декларативность?
Может быть она просто не абсолютная декларативность?

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

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

Думаю можно сделать язык который все не явные противоречия разрешает, но возможно просто не достаточно вычислительных мощностей.
Я прекрасно понимаю почему Пролог не декларативен. Но это уже второй вопрос. Первый — это описываем ли мы задачу в терминах предметной области или «в порядке, в котором машине будет легче понимать». И тут — Пролог «проваливается» по полной. У нас в проекте много разных декларативных описаний (не универсальных, конечно) и ментальная проверка «а что будет, если мы это описания случайным образом перемещаем» — первое, что делается, когда DSL разрабатывается.

И да, то, что Пролог — не декларативен неделает его бесполезным. Но я не понимаю почему его все пытаются «продавать» как декларативный язык — притом что он таким ни разу не является.
Это пример практической некоммутативности связки ИЛИ. Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :) Так и и пролог. Проблема не в нем, а в природе логики.
Это пример практической некоммутативности связки ИЛИ.
Извините, но это бред. Эти два правила для любой пары объектов дают ровно один ответ на вопрос «является ли Исаак предком Иакова» — независимо от порядка.

Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :)
Это называется — императи́вное программи́рование

Проблема не в нем, а в природе логики.
Нет — проблема в том, что некоторые люди не умеют отличать декларативное программирование от императивного.

Пролог просто является классической подменой понятий: вначале нам объясняется, что Prolog является декларативным языком программирования, а потом — объясняется как работает Prolog-машина и оказывается, что мы должны не писать декларативное описание этой задачи, а программировать вот эту вот, вполне императивную, машину…
Если вы хотите сделать что-то с практическими результатами, вам придется разбираться с порядком применения правил — равноправия на практике обычно не получится. Перепишите мой пример в виде «налево — потеряешь голову» ИЛИ «направо — получишь приз» — какая тут императивность, 100% декларативность, но от того, за что вы возьметесь в первую очередь, зависит результат.
UFO just landed and posted this here
Если вам нужна теория для её самой, то разницы о очередности нет, а если вы что-то хотите от теoрии практического, то есть. Это и отражается в прологе, как в практическом инструменте. Если кто-то останется без головы, то приз получать уже будет никому. Декларативность предполагает обычно слишком много вариантов и зацикливание — это тоже вариант. От перемены местами дизъюнктов в вашем примере вы его и получаете. В 90-е кто-то предлагал вариант пролога с со случайным выбором — интересный подход, но, полагаю, что он сильно понижает производительность работы. Кому нужен ответ, полученный через 100 лет? Получается выбор: 1) изобретать замысловатые системы логики, конкурировать с Аристотелем; 2) пытаться сделать эффективные машины логического вывода — это пролог, SQL, скорее неудачный и несостоявшийся меркурий,…
Ещё раз, для идиотов. Цитирую:

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

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

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

Можно сколько угодно рассказывать про сложности работы со спецификациями, но практически — вы либо умеете с ними работать, либо нет. Пролог — не умеет. Он умеет работать только со специцикациями заточенными под Пролог-машину и учитывающими то, что у неё «под капотом». Какая тут, нафиг, декларативность?
Исключительно ради занудства, а не для того чтобы с кем-то о чем-то поспорить:
Какая тут, нафиг, декларативность?
Ответ — ограниченная. У пролога декларативность ограничена тем что у него под капотом. Но это не делает его не декларативным, это делает его «всего лишь» бесполезным на практике.
3ря вы так. Пролог или какое-то его удачное расширение — это будущее программирования. Пролог это почти 100% математика, тогда как другие языки — это смесь математики и отсебятены.
Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата. Но это так только в случае действительно 100% точного описания задачи. Порядок дизъюнктов — это один из элементов такой точности.
Пролог или какое-то его удачное расширение — это будущее программирования
Он может быть и будущее, но на данный момент он все равно бесполезен на практике. Одно никак не противоречит другому.
Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата.
Мой комментарий был вообще не об этом. Мой комментарий был о двух вещах — о том, что пролог крайне ограничен в множестве задач на которых его можно применять и, следовательно, не помогает в решении практических задач. Но при этом он остается декларативным, ограниченность принципу декларативности не мешает насколько я понимаю. Даже математически не мешает.
Он может быть и будущее, но на данный момент он все равно бесполезен на практике.

Не могу с таким согласиться. Существует достаточно много перспективных проектов вокруг пролога. Пролог — универсальный язык и на нём можно делать всё, что, например, на питоне. Может просто нужен кто-нибудь типа Гвидо, который сделает популярный вариант пролога. Скорость работы хороших прологов на уровне языков сценариев. Мне кажется полезность-перспективность и текущая массовая популярность — это разные вещи. Мое мнение — пролог это один из самых простых и близких к естественному языков программирования. К сожалению, приходится до сих пор больше работать сo скорее с потомками фортрана. :(
Существует достаточно много перспективных проектов вокруг пролога.
Только перспективных или уже реально широко используемых? Если первое, то с его возрастом это диагноз на мой взгляд. Если второе, то интересно было бы посмотреть на пример.
Понимаете, это же достаточно объективно — если инструмент полезен и достаточно стар чтобы его успели попробовать, то на нем будут что-то делать. Если инструменту много лет, о нем много кто знает, но при этом ничего практического на нем нет — значит он бесполезен.
Не всегда это говорит о бесперспективности. Нейронные сети исследуются полвека, но активно использоваться стали лет 10 назад, не больше. Но там понятно чего не хватало: скорости. Традиционные подходы сложнее в программировании, но требуют на порядки меньшие ресурсы.

А чего Прологу не хватает, интересно? У меня есть ощущение, что как раз декларативности: современные системы многопоточны (а GPU — так сильно многопоточны), но как раз декларативно описанные задачи параллелятся «в лёгкую», а вся семантика Пролога завязана на его однопоточную машину…
Не всегда это говорит о бесперспективности.
Я и не говорил «бесперспективный», я говорил «бесполезный», что предполагает выгоду от его использования сейчас, а не когда его наконец-то допилят. Допилят ли, и может ли оно взлететь тогда — отдельный вопрос.
Довольно много проектов, связанных с машинным обучением с использованием обучаемых сетей. Также есть проекты для работы с естественным языком. Всего тут довольно много и меньше не становится. Почему процент пролог-проектов в целом небольшой? Возможно потому, что сложилась некая культура программирования на С-подобных языках (возьмем, например, APL, оберон, аду или эйфель — их тоже не больше, а скорее меньше, чем пролога), к которой привыкли и которая пока адекватна решаемым задачам. Пролог требует специальной подготовки, которой нет у многих топовых специалистов. В самом прологе не хватает многих отточенных на типовые задачи механизмов, которые появятся только, если сделать его очень популярным. Вокруг специального железа для пролога какой-то туман, возможно секретности. И, могу предположить, что широкое внедрение пролога сделает большинство ЯП устаревшими, к этому пока не готовы.
Примеры проектов покажете? Интересны именно проекты, которые можно использовать.
К сожалению, прологом сейчас практически не занимаюсь. Но посмотрите страничку в википедии: Watson — очень серьёзная система и работает в штатном Линуксе. Там же приводится цитата: «We required a language in which we could conveniently express pattern matching rules over the parse trees and other annotations (such as named entity recognition results), and a technology that could execute these rules very efficiently. We found that Prolog was the ideal choice for the language due to its simplicity and expressiveness.» Pазработка компиляторов с использованием пролога имеет несколько неоспоримых достоинств. Погуглите prolog projects и обнаружите десятки развивающихся систем программирования, основанных на идеях пролога. Аналогично, prolog deep learning. Если вы проведете подобные изыскания по аде, коболу, эйфелю и др. не самым распиаренным языкам, то найдёте, что у пролога всё относительно неплохо. Предположу, если кто ищет себе комфортабельный вагончик, то пролог пока ещё до этого не созрел. А тому кто хочет быть локомотивом, пролог предоставляет огромное и очень перспективное поле для деятельности.
Вам привели пример, что описание задачи может приводить к разным результатам. И ваш пример о том же. А вы что хотите, чтобы машина ещё и знала, что Вам нужны предки библейских персонажей немедленно, а не её усердная работа по их поиску на миллионы лет? Хотеть не вредно. Но лучше давать машине уточнения в таких случаях. В прологе такие уточнения — это, в частности, порядок дизъюнктов и предикатов в них. Предлагаю учить пролог и yчить тщательно!
SQL вполне себе императивен, если вы освоили концепцию «вложенных циклов»
Ну, можно и суп палочками есть…
Да ну, перешёл с джавы на си для своих проектов — наоборот, всё стало гораздо проще. Не нужно писать ненужный бойлерплейт в угоду ООПшным шаблонам проектирования, питать надежды, что всё это влезет в память, а не упадёт с OOM, профилировать перформанс — и так ясно, что всё предельно быстро будет и без задержек на GC, не нужно думать о том, откуда на клиентском устройстве JVM возьмётся, почти не нужен рефакторинг, т.к. без классов функции никак друг с другом не связаны.
Отличный язык для быстрого прототипирования) Просто фигачишь функции и они просто работают)
всё предельно быстро будет

Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками? И программа работает на x84/x64/arm/aarch64 без компиляции? И векторизация инструкций тоже будет использоваться, да? И порядок инструкций поменяется на лету, ради скорости, да?


без задержек на GC

Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?


не упадёт с OOM

Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?


Отличный язык для быстрого прототипирования)

А для боевого применения?


на клиентском устройстве

А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?


Если подытожить: Ваши аргументы крайне спорные. И далеко не так очевидно, что С быстрее, удобнее и т.д.

Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками?
Не требует.
И программа работает на x84/x64/arm/aarch64 без компиляции?
Какая разница, +1 архитектура — всего лишь строчку в мейфайл добавить и поставить компилятор, что куда проще и симпатичнее, чем например, jvm под iOS запихнуть в дистрибутив приложения.
И векторизация инструкций тоже будет использоваться, да?
Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.
И порядок инструкций поменяется на лету, ради скорости, да?
Если порядок меняет результат вычисления, и при этом нет грубых нарушений правил языка, ничего не поменяется.
Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?
На практике вклад malloc/free во время исполнения с лупой искать надо.
Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?
Да вроде не течёт, тем более сама)
А для боевого применения?
Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.
А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?
Для отладки компилятор зашивает в бинарник всё необходимое, при чём здесь ОС и процессор. В С я могу включить в отладочных целях проверки обращения к памяти например, как в той же Java, в релизе могу выключить и получить прирост производительности, а в Java — нет, не доверяет она разработчику.
всего лишь строчку в мейфайл добавить и поставить компилятор
Это так просто не работает.
Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.

Покажите ваш проект на си, чтобы один раз, да сразу для iOS и для веба и для винды.
Пока рано что-то показывать, однако не вижу, что мне помешает OpenGL приложение собрать под разные платформы. Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.
Между «теоретически возможно» и «устоявшаяся технология, экономящая время» огромная пропасть. И она, с огромной долей вероятности, для Си не будет преодолена.

Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.

Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть? Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.
Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть?
Переиспользуется как раз почти всё, написание чего требовало каких-то усилий. Обёртка под андриод — уровня хэлловорлда, причём даже не написанная, а тупо позаимствованная из NDKшных примеров.
Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)
Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.

Вот только использование Си для написания приложений сразу под веб и все остальные платформы — не устоявшийся кейс. Можете показать какие-то инструменты для этого, сравнимые с React Native?

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

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

Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)

Я вам ещё раз повторю написанное: компании, использующие инструменты с огромным комьюнити, покрывающие гораздо более простые кейсы (iOS+Android), сомневаются в целесообразности этого. Именно с денежной точки зрения.
Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.
И есть простые примеры типа такого github.com/redblobgames/helloworld-sdl2-opengl-emscripten

Себе я запилил удобный фреймворк, на котором приятно работать, вот например разметка + внешний вид + добавление кнопки:
static LayoutsParams lbPersNew = {.width = 320, .height = 96, .gravity = CENTER_HORIZONTAL | TOP, .marginTop = 8, .marginTopPercent = .333};
static TextureParams tbPersNew = {.texLeft = 225, .texTop = 249, .texRight = 263, .texBottom = 287};
static NinePathParams nbPersNew = {.vertTop = 16, .vertBottom = 16, .horLeft = 16, .horRight = 16};
//...
void initGui() {
    bPersNew = BUTTON(0, &onPersNewPressed, &lbPersNew, &tbPersNew, &nbPersNew, VISIBLE);

//…

Вы видите здесь что-то платформоспецифичное? Разметку и другие параметры я могу объявить в другом файле, если захочется разный вид приложения на разных платофрмах сделать, могу как есть оставить.
Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.

Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript. Во-вторых, вы же в курсе что люди не только игры пишут, да?

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

.width = 320

320 чего?
320 чего?

Масштабируемых единиц, конечно же)
вы же в курсе что люди не только игры пишут, да?
У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.
Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript.
Я уже писал, что по моим ощущениям, С уменьшает сложность по сравнению с C++ или C#. На С++ код иногда без боли не взглянуть.
Масштабируемых единиц, конечно же)

Вы же в курсе, что в браузере их не существует?
У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.

Как думаете, ваше приложение пройдёт ревью в App Store?
Как думаете, в AppStore есть игры с виджетами на 3д графике и непонятно какой логикой мастшабирования?
Вы же в курсе, что в браузере их не существует?
выбор коэффициента масштабирования — задача платоформозависимой обёртки, можно положить =1, если лучшего решения не найдётся.
Всё ещё не понимаю что вы хотите сказать.

Что на Си можно написать на движке игру и она будет работать на всех платформах? Нет, нельзя. Зато можно сделать на C# или C++.

Что можно написать на Си кроссплатформенное приложение? Нет, нельзя. Как минимум, вам придётся создавать UI на OpenGL с нуля. Чем вы и занимаетесь.

Что вы можете написать велосипед и добавлять в него платформы со временем? Ну удачи. Наберёте когда сделаете 3-4. Как раз с точки зрения финансов это просто выброшенные на ветер деньги. Только какие тут преимущества у Си?
Благодарю за комплимент, очень приятно слышать, что я делаю невозможное. У меня сложность не в UI, он уже есть и работает на 2х платформах как минимум (Android + Linux + Mac (?) Windows(?)), где (?) — не протестировано, но должно работать без изменений. Профит для меня как разработчика самый прямой — если раньше я просто шлёпал формочки, то сейчас в резюме могу дописать больше интересных вещей и продать своё время дороже, + 50%...100% — это более чем окупит потраченное время, если пересчитать на стандартную оплату труда. Это минимум. Цель — запустить крутой продукт и заработать о***лиарды)

Только какие тут преимущества у Си?
Вы видели эти божественные скобочки, которые я выше привёл? Я могу частично инициализировать структуру! Да это же как JSON! Я могу на си описывать UI с такой же лёгкостью, как JSON написать! В С++ такого нет, в джаве нет, в андроид блеклая эмуляция декларативного описания через XML, в iOS муки и матюки на StoryBoard или как там их инструмент разметки называется, несовместимый с git, в котлин чуть удобнее сделали, но всё равно не то.

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

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

Си замечательно дружит со многими другими языками. Я могу просто закинуть сишные файлы в проект на С++/objective-C/D, вроде Swift тоже, могу подключить к проекту на Java через jni, могу сишную либу слинковать с любым другим компилируемым языком. У С++ тут уже начинаются проблемы.

Далее, Си — простой для чтения и написания язык. Я могу показать код программисту на Java/C++/JS/C# и пр., и он гарантированно поймёт, что тут проиходит. Можно смотреть его в плейнтекст и не ломать голову, что это за auto.

Си программы быстро компилируются и быстро запускаются, за 1 секунду я могу собрать (инкрементально) проект и запустить приложение, полная пересборка всего ~4c, а в Java я успею попить кофе, пока всё соберётся, в С++ и подавно.
В С++ такого нет
Чего нет? Designated initializers? Поддерживаются уже лет 10 clang'ом и GCC, включены в C++20. В MSVC, да, беда — ну так там их с в C нет, ибо C99 MSVC не поддерживает.
UFO just landed and posted this here
Map написал уже, синтксис другой немного, суть та же: берём список элементов одного типа, создаём из него список элементов другого типа по коду в скобках.
image
Использование:
image
UFO just landed and posted this here
А давайте сравним перформанс и читабельность кода? В бусте я Map в смысле преобразования списков не нашёл, так что через std::transform
C:
image
time ./cppapplication_4
el = 1
el = 11
el = 21
el = 31
el = 41
el = 51
el = 61
el = 71
el = 81
el = 91

real 0m0,583s
user 0m0,486s
sys 0m0,097s

с++:
image
time ./cppapplication_3
foo contains: 11 21 31 41 51 61 71 81 91 101

real 0m3,828s
user 0m3,734s
sys 0m0,092s

Разница по времени не в пользу С++, да и читаемость так себе.

А давайте сравним с Rust:


vec.rs:


fn main() {
    let vec = vec![0; 100000000];
    vec.into_iter().enumerate()
        .map(|(idx, _el)| idx * 10)
        .map(|x| x + 1)
        .take(10)
        .for_each(|x| {
            println!("el = {}", x);
        });
}

Компиляция:


$ rustc vec.rs -O

$ time ./vec 
el = 1
el = 11
el = 21
el = 31
el = 41
el = 51
el = 61
el = 71
el = 81
el = 91

real    0m0.003s
user    0m0.003s
sys 0m0.000s

Поиграться с кодом на playground


OMG пыщ-пыщ РАСТ БЫСТРЕЕ С в 200 раз и быстрее С++ в 1200 раз!!!111

Сомнительный бенчмарк, сэр. Тем не менее, этот сомнительный бенчмарк показывает, на что способен оптимизатор Раста =)

На самом деле это было на ленивых вычислениях. Тем не менее, без ленивых вычислений:


fn main() {
    let vec = vec![0; 100000000];
    let vec: Vec<_> = vec.into_iter().enumerate()
        .map(|(idx, _el)| idx * 10)
        .map(|x| x + 1).collect();
    vec.into_iter()
        .take(10)
        .for_each(|x| {
            println!("el = {}", x);
        });
}

real    0m0.281s
user    0m0.072s
sys 0m0.208s

А в C++ версии вы сделали инициализацию массива из 100000000 элементов с помощью push_back, не удивительно, что оно так тормозит. Вы-то себе пачкой выделили память.


Читайте про амортизированную стоимость.

То с дебажным флагом компилятора было, с -03
real 0m0,133s
user 0m0,072s
sys 0m0,061s
И это я ещё OpenMP не подключил для автопараллелизации циклов)
Раст прикольная конечно штука, но пока экзотика)

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


ArrayListTest.c:


real    0m0.497s
user    0m0.292s
sys 0m0.205s

cpp:


int op_increase(int i) { return ++i; }

int main() {
    std::vector<int> foo;
    foo.reserve(100000000);

    for (int i=0; i<100000000; ++i) foo.push_back(i*10);
    std::transform (foo.begin(), foo.end(), foo.begin(), op_increase);

    for(size_t i = 0; i<10; ++i) {
        std::cout << foo[i] << std::endl;
    }
}

real    0m0.254s
user    0m0.148s
sys 0m0.108s

rust (вариант выше):


fn main() {
    let vec = vec![0; 100000000];
    let vec: Vec<_> = vec.into_iter().enumerate()
        .map(|(idx, _el)| idx * 10)
        .map(|x| x + 1).collect();
    vec.into_iter()
        .take(10)
        .for_each(|x| {
            println!("el = {}", x);
        });
}

real    0m0.286s
user    0m0.097s
sys 0m0.189s

rust (параллельные итераторы):


use rayon::prelude::*;
fn main() {
    let vec = vec![0; 100000000];
    let vec: Vec<_> = vec.into_iter().enumerate()
        .map(|(idx, _el)| idx * 10)
        .map(|x| x + 1).collect();
    vec.into_iter()
        .take(10)
        .for_each(|x| {
            println!("el = {}", x);
        });
}

real    0m0.112s
user    0m0.302s
sys 0m0.314s

Пока что лидирует Rust =)


И это я ещё OpenMP не подключил для автопараллелизации циклов)

Только код скиньте.

UFO just landed and posted this here
github.com/yarston/ArrayListTest выложил сюда. собиралось c gcc -g в прошлом посте.
Сделал вариант бенчмарка с пушем в список по 1 элементу.
Вариант с пушем с -O3:
make && time ./a.out
real 0m0,394s
user 0m0,321s
sys 0m0,073s

С единоразовым выделением памяти gcc -O3:
make && time ./a.out
real 0m0,133s
user 0m0,072s
sys 0m0,061s

Проц i73630QM 2.2 ГГц
Ну и, кроме того, как-то мы резко сменили тему с написания сишного map на микробенчмарки
Ну он написан же, что там ещё обсуждать. Перформанс вроде как важен для сишников.
void* add2ArrayList(ArrayList *list) работает несколько не так как в C++, он не добавляет элемент сам, а только увеличивает счётчик, если надо, реаллоцирует и возвращает указатель, по которому уже можно писать данные. Например, указатель на структуру.

Кроме того, это немножко читерство: в плюсах вы не выделили всё место сразу, а в С — выделили.
На самом деле я скопипастил плюсовый код с какого-то сайта. Ну вот пишут они так.
UFO just landed and posted this here
у меня сишка чего-то тормозит:
странно, у меня
gcc --version
gcc (SUSE Linux) 8.2.1 20190204 [gcc-8-branch revision 268513]
Правда у меня ещё патчи против спектр отключены. Там getSlow() по умолчанию стоит, его можно закомментить и собрать с единоразовым выделением памяти.
Нет, там написан не он.
Звучит как повод для дискусси, но лень спорить) Да и ладно, списки крутятся, работа мутится.
Если убрать bar и писать сразу в тот же foo, то получаем 0.18 с.
это уже другая задача.
UFO just landed and posted this here
Нет наверно, спать охота, и тут запрос на webassembly порт поступил. Почему у вас такие цифры времени исполнения — для меня загадка, на вашем процессоре быстрее должно же быть по идее.
UFO just landed and posted this here
Замена
CONVERT_VEC_TYPE(unsigned, in, list, unsigned, out, list2) *out = *in + 1;
на
 FOR(unsigned, el, list) (*el++)++;
:
make && time ./a.out
gcc -O3 list.c main.c
el = 1
el = 10
el = 21
el = 30
el = 41
el = 50
el = 61
el = 70
el = 81
el = 90

real 0m0,090s
user 0m0,070s
sys 0m0,020s
UFO just landed and posted this here
Да, спать пора) Инкремент указателя внутри макроса же делается.
FOR(unsigned, el, list) (*el)++;

gcc -O3 list.c main.c
el = 1
el = 11
el = 21
el = 31
el = 41
el = 51
el = 61
el = 71
el = 81
el = 91

real 0m0,089s
user 0m0,060s
sys 0m0,028s
UFO just landed and posted this here
Ну у меня DDR3, ноут 13года что ли.
UFO just landed and posted this here
Ехал this через this, сунул this в this auto, this this this this this this this this)
Ты в золотой середине. Можно дрова писать и приложения для людей. Мы спрыгнули в начале 90-х с С и подобных языков в погоне за баблом. Тогда нужны были бухгалтерско-банковские десктопно-локально-сетевые проги. Брали Clipper, написанный на С, и за месяц рисовали то, что на С создавали бы год. Поэтому, если С есть наработка и не происходит отставания по времени исполнения проектов от конкурирующих языков, то жаба — это ничто по сравнению с С, тем более, что на кофеварке крест ларри поставил, но никак не может сдать в утиль. Вторая сторона луны — это где найти команду сишников, которая гребет не меньше жабокодеров. Т.е., сравниваем, сколько бабла дает С по сравнению с другими.
Вот это вы понаписали! Встану ка и я на защиту Си. В общем, будущее идёт к тому, что для платформы браузеров (я имею в виду JS-виртмашину, что в браузерах) скоро web-приложений написанных на Си (точнее включающих исходники на Си) будет больше и больше. Сейчас Emscripten набирает обороты. Скоро подправят WebAssembler и будет неплохая браузерная виртмашина для Си. Многие Си-шные вещи уже в браузере есть или подцепляются с некоторыми доработками. Прирост скорости ощутимый. А если рисовать всё на OpenGL то хоть под десктоп пиши хоть под браузер. Страницы могут перейти с html на JS-байткод, грузится быстрее, не парсится, не компилируется, и… прощай стандартный html и JS-скрипты, здравствуй Си! Скоро Linux под браузером запустят…
Уот это поворот! Я всё проспал.
Винда 2000 в браузере тоже порадовала.
Значит и динамическая кодогенерация на Си с Tiny C Compiler тоже появится. Во время то пошло.
UFO just landed and posted this here
Если в смысле динамической компиляции, то Cи тут не особенный. Но Си становится особенным в смысле своего более раннего происхождения и как следствие довольно большой кодовой базы которая была наработана и отлажена за всё время существования языка.
довольно большой кодовой базы которая была наработана и отлажена за всё время существования языка
Кодовой базы которая наработана, но не отлажена в нем также больше. Поиски работающего кода для своей конкретной задачи — отдельная проблема которая далеко не всегда проще чем собственно написание своего решения. А уж поддержка кода который написали не вы…
Кстати, например, Flutter (скорее всего и другие аналоги) пошел по этому пути. Он есть ничто иное, как 2d движок по типу игрового, но отрисовывает только виджеты и тп) Гениально!) Сишные бинарики просто идут в комплекте с приложением
Да, вот гугл тоже в этом направлении думает.
Вы видите здесь что-то платформоспецифичное?

Да. 9-patch это андроидовская тема.
В чём у вас измеряются все магические константы — непонятно.
У меня кроссплатформенная реализация. 320 dp.
В кроссплатформенных движках есть свои библиотеки и методы работы с конкретной платформой. Но что бы разработчикам игр было проще, разработчики движка стараются унифицировать внутренние функции под каждую платформу. К примеру, некоторое время назад для UE4 я собирал доступные в Marketplace технодемки, пробовал комбинировать и с DX11, и с OpenGL 4, и с Vulkan (хотя он в экспериментальном варианте). В практически большинстве случаев демки идут так как и должны, выглядят как должны, хоть на Windows, хоть на Linux. Это и есть та самая кроссплатформенность и удобство сборки, о чём выше вы и сказали.
На iOS без плясок с бубном уже не взлетит.
Потому что Metal? Переписать вызовы OpenGL на Metal должно быть несложно, суть-то одна, названия методов только отличаются.
UFO just landed and posted this here
И компиляторы уже такие умные стали, что автоматически векторизуют всё, что можно векторизовать?

Ну у меня например, софтварный растеризатор треугольников на Си без интрисинков с опцией -O3 ~180мс на отрисовку сцены 8к полигонов в 4к (3840*2160) в 1поток на ноутбучном CPU, а с интрисинками (SSE4.2), оптимизацией размещения данных в структуре и выравниванием в памяти ~160мс. Пожалуй под неон забью на ручную векторизацию.
Может, оно вам и AoS в SoA само конвертирует?
А зачем? Я сразу пишу как надо.
У меня бывают проекты, где приходится писать свои аллокаторы, с аренами и вот этим всем.
В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.
UFO just landed and posted this here
Кто лучше решение может предложить? Java? .NET? У них ещё меньше информации.
UFO just landed and posted this here
Растовые лайтфайфы не подойдут?
UFO just landed and posted this here
Ну вот мы знаем размеры объектов, времена жизни. Что еще надо? Просто проблему не понимаю.
UFO just landed and posted this here
Ну сделать это локально не очень трудно.

А глобально да, в голову ничего не приходит.
UFO just landed and posted this here
Реюзать функцию без ссылок на this проще, чем с. Нет ООП — нет this. Чистые функции как они есть.
UFO just landed and posted this here
Обычно люди просто стараются увернуться (включить/выключить, попробовать ещё раз), а не выяснять что именно там случилось.

Так ещё Чарльз Беббидж говорил, что выгоднее (по времени) пересчитать заново всю ошибочную страницу, чем искать в ней ошибочные значения.
Всякая абстракция имеет дыры. Целые «числа» имеют максимально возможные значения. Вещественные переменные на самом деле имеют ограниченный набор дискретных значений.
Вычитание из большого числа маленького может не приводить к изменению значения. И т.д.
Но стек абстракций уже слишком велик, чтобы кто-то мог его весь знать в подробностях.
Мы не чиним двигатель через выхлопную трубу. Мы едем на СТО и просим специалиста залезть пд капот.
задача всего компьютерного — абстрагирование и уменьшение сложности.


Иногда программисты старшего поколения, глядя на сегодняшние реалии начинают всерьез в этом сомневаться… Я вполне знавал людей, которые считали, что ассемблер гораздо ПРОЩЕ всех этих ваших «высокоуровневых» ЯП. И где-то они правы… Пока сложность собственно самого кода не выходит за определенный порог, когда без абстракция уже невозможно охватить сознанием логику решения в целом.

Но все равно — текущий уровень абстракции многих современных ЯП даже мне кажется слишком перегруженным! Ощущение такое, что уже пошли абстракции, ради абстракций, размывающие основы. Согласен во многом с автором.
Тот странный момент, когда осознаёшь что ты уже относишься к «программистам старшего поколения»… :)
Проще понять как оно устроено. Да, старые системы устроены проще с точки зрения нижележащего уровня.

Но я реально не понимаю, сколько строк кода на ассемблере нужно для того, чтобы скачать файл. tcp, DNSsec, TLS, http…
Если не писать все самому, а дергать уже готовые библиотеки, то вряд ли так уж много. Все равно на порядок (если не на два) больше, конечно, чем на каком-нибудь питоне, но не запредельное количество вроде бы. Впрочем я ассемблером занимался последний раз давно и на память не вспомню что там есть из доступного что можно дергать чтобы скачать файл. Может быть я ошибаюсь и нет ничего.
Ну да… Если include 'win32a.inc', то дальше почти как на высокоуровневом:

; Открыть интернет-соединение
invoke InternetOpen,user_agent,\
INTERNET_OPEN_TYPE_PRECONFIG,NULL,NULL,0
mov [hInet],eax

; Открыть FTP-соединение
invoke InternetConnect,[hInet],server,[port],login,password,\
INTERNET_SERVICE_FTP,INTERNET_FLAG_PASSIVE,0
mov [hConnection],eax

И тп…
Там, где «и тп...» )))

Это был просто пример подхода к вопросу «скачать файл», если есть библиотека.

Так-то tls Гуглится на раз.
Я вполне знавал людей, которые считали, что ассемблер гораздо ПРОЩЕ всех этих ваших «высокоуровневых» ЯП.

"Сложность" в данном случае — это не сложность инструмента, а сложность решения задач при помощи этого инструмента. Экскаватор сложнее лопаты и требует более высокой квалификации от того, кто его использует, но копать котлованы при помощи экскаватора в итоге проще. Ассемблер — лопата, ЯП ВУ — экскаватор.

Хорошая аналогия… Ее же можно развивать? ;)

Например лопатой можно делать гораздо более точные и аккуратные вещи, в быту нужна лопата, а не экскаватор, порог вхождения у лопаты… Тонкий момент — у лопаты ниже, а ассемблера — не факт… ;)

Потом опять же — лопата, она и есть лопата, а сложность современных экскаваторов ЯП уже как-то слабо коррелирует со сложностью решаемых задач! Современный Hello world запросто может потянуть на пару десятков килобайт, и примерно никто 90% тех, кто его использует НЕ ЗНАЕТ, что там в этих килобайтах!

Львиная доля усложнения самих ЯП (я имею ввиду не банальный синтаксис, а совокупность код/ide/продукт на выходе) идет на сокрытие реальной сложности от разработчика. А многократный запас по производительности позволяет не парится из избыточностью и не рациональностью в угоду универсальности.

Это, наверное неплохо, но… Иногда мне тоже кажется, что мы пройдем какую-то точку, после которой все это превратится в магию, потому, что никто не будет знать, как оно работает!
Кстати, о сложности — ниже рабочая программа на OpenGL

#include <GL/glut.h>

int main()
{
glutCreateWindow(«Small program»);
glutDisplayFunc([]{});
glutMainLoop();
}

Лопата при кажущейся простоте ушатает руки в первый же день работы, и вообще копать ей — адское занятие.
Потом опять же — лопата, она и есть лопата, а сложность современных экскаваторов ЯП уже как-то слабо коррелирует со сложностью решаемых задач! Современный Hello world запросто может потянуть на пару десятков килобайт, и примерно никто 90% тех, кто его использует НЕ ЗНАЕТ, что там в этих килобайтах!

Экскаватор тоже тянет на несколько тонн. И 90% тех, кто им управляет, не знает, что там внутри :)


Львиная доля усложнения самих ЯП (я имею ввиду не банальный синтаксис, а совокупность код/ide/продукт на выходе) идет на сокрытие реальной сложности от разработчика.

Ну так да, уменьшение сложности. В этом смысл и состоит.

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

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

А разве это проблема только программирования? Нучно-технический прогресс вообще приводит к узкой специализации.
Недавно вспоминал, как в стройотряде нашу бригаду прикрепили к комунхозу.
Срочно привозят на место происшествия: стоит экскаватор, на ковше вытянутый из земли высоковольтный кабель, изоляция уже лопнула и металл блестит. Экскаваторщик сидит в сторонке белый как бумага. В результате мы траншею копали лопатами.
Очень актуальная аналогия :)
Не готовы потерять контроль? Как было сказано: «Принеси ведро электронов!»
> Все эти картинки у тебя на мониторе, циферки, библиотеки, анимации — они не настоящие. Настоящее только электричество.
Так и мысли в голове не настоящие. Это несвязной бормотание внутри головы — это только тень от того, что происходит за пределами сознания. В каком-то смысле, сознание и есть то, что мы можем сказать. Чтобы сделать тривиальное действие, например, выделить немного слюны — мы должны очень напрячься, воображая лимон.
И этот же подход мы перенесли на программирование. Чтобы отправлять тривиальные сигналы, мы создали какие-то абстракции, которые нашему сознанию более близки, которые проще вообразить. Мы, условно говоря, мыслим «лимонами», а наше тело и компьютер управляется условным электричеством. И наши ЯПы — тем для нас лучше, чем они ближе к «лимонам». А что они там под капотом делают — дело уже давно десятое. И в принципе, оно хорошо. Если завтра у нас компьютеры будут основаны на других принципах, то нам достаточно будет переписать наши интерпретаторы лимонов в это новое и оно будет как-то там работать. Это тоже контроль. Но другого типа.
Электричество тоже не настоящее. Оно течет в ненастоящих кристаллических решетках, которые сделаны из ненастоящих атомов, которые сделаны из ненастоящих электронов и ядер, которые сделаны из ненастоящих кварков, которые…
По-моему, все от мало до велика виртуально)
и ваще, мы с вами сейчас находимся в Матрице
Заголовок спойлера
Wake up, Neo…
Читаем теорию электромагнитного поля (3-я, завершающая часть электротехники). Это, самое, электричество — оно даже не течет. Это поле. Технология эл.проводов — это древность, но бизнес, как нефть, перегаром которой нас вынуждают дышать.
Скорее здесь уместнее будет аналогия с естественным языком и речью. По-началу речь проста и незамысловата, ее цель — донести суть. По мере развития человека (человечества?) суть донести все сложнее и речь усложняется. Узких специалистов зачастую понять может уже только такой же специалист…

Однако есть, условно, наука, а есть наукообразность. Есть области, где просто нельзя без усложнений, а есть люди крайне витиевато и сложно выражающие ЛЮБУЮ мысль — даже ту, которую можно донести трехлетнему ребенку десятком простых слов.

Есть канцеляризмы, есть сленг, арго и тп.

Вот и не понятно где усложнения были необходимы, а где кого-то просто перло от нагромождения абстракций!

А если серьёзно, то проблема построения абстракций над абстракциями (и так до бесконечности) очень-очень серьёзная. Хорошо, если хоть четверть веб-разработчиков знают и понимают, что под капотом у V8, сишарперы — у IL. И как только мы встречаемся с проблемой уровня ниже нашего предела понимания этих абстракций, мы бессильны.
Ещё Азимов в своей книжке "Основание" описал, а Артур Кларк сказал, что любая достаточно развитая технология неотличима от магии. А разве мы можем понять магию? Нет. Не можем. Значит рано или поздно, при появлении таких технологий, мы будем жить в мире компьютерной магии, и ни один человек не будет ей управлять.


А теперь представьте, если магия перестанет работать. Что будет? Полная разруха...

Как жаль, с одной стороны, что нет инопланетян, и никакое НЛО не починит… Но с другой стороны, хорошо, что никто не может нас шантажировать в плане контроля и починки этой "магии".

Вы не совсем уловили что я хотел сказать. Я к тому веду что кто-то этим управлять в любом случае должен. Если не инопланетяне то сами люди, те кто эту технологию разработал или их наследники. Чтобы некая технология работала но при этом никто не знал как — нужны весьма специфичные условия. Это в глобальном смысле, само собой.
Вы знаете, вот это вот Всё мне частенько напоминает о книге Герберта Уэллса — Машина времени (посмотрев кино версию этого не ощутить). Хоть я и читал её лет 20 назад. Но иногда сталкиваюсь с тем во что оно может «интерпретироваться» и нахожу параллели. Как бы мне не хотелось чтобы мы не создали случайно эти самые специфичные условия. Гуманитарии там тоже по своему интерпретированы=)) они живут под землей и чинят механизм какой-та, а по ночам выходят и хавают илиту, живущих на поверхности, безвольных
Вы знаете, мне иногда кажется, что в современном мире достаточно уничтожить 15-20 тысяч человек, чтобы цивилизация встала в своём развитии. Пугает…
Даже если предположить что предположение верно, вы правда не считаете специфичными условиями внезапное уничтожение 15-20 тысяч конкретных людей?
Да все эти конкретные люди географически в одном месте сосредоточены, к тому ж сейчас отдельные, даже очень образованные и знающие, люди не смогут восстановить технологию если ее утерять, технология на команды и оборудование завязана, уничтожь большую часть команды и оборудования и технологию не восстановить.
Сколько мест в мире где скажем жесткие диски делают или еще чего там более продвинутого? А если их 1-2 таких мест на весь мир останется, глобализация экономики это же диктует, а потом какой локальный кабздец на это место свалится типа эпидемии или военного конфликта. Т.ч. специфичность условий тут скорее в локализации технологий, а не сами условия, о чем мне думается предыдущий оратор и говорил.
Сколько мест в мире где скажем жесткие диски делают или еще чего там более продвинутого?
Жёсткие диски ладно. А вот сканеры для литографии — это штучная работа и всего три фирмы: ASML и Canon и Nikon их делают (вернее практически ASML только делает, Canon/Nikon всё грозятся победить EUV, но пока поставок нет).
Вы знаете, мне иногда кажется, что в современном мире достаточно уничтожить 15-20 тысяч человек, чтобы цивилизация встала в своём развитии. Пугает…

американцы вон уже список в санкциях начали заполнять=)) осталось ещё сотню таких составить, и заживём
Вы заблуждаетесь. Локальные технологии могут держаться на маленькой группке людей, глобальные — нет.
Предположим некоторые рептилоиды с помощью наноботов взяли и уничтожили весь интел и амд. Ну и производственные их мощности заодно и складские запасы, так уж, чтобы наверняка. Что произойдёт?
Ну экономику поколбасит, да. Цены полезут вверх на железо как на дрожжах, стартапов поуменьшится.
Но
1) останутся сотни мелких производителей
2) Новые процессоры х86 выпустят в течение двух, максимум пяти лет
3) технологии на фабах откатятся ну скажем на десять лет назад
4) станут востребованны более быстрые стеки ПО

В целом эффект на прогресс это окажет не очень сильный.
Так надо не компании уничто жать, а специалистов. Если уничтожить всех разработчкиов и все чертежи, человечество не сможет востановить архетектуру. Максимум через несколько десятелетий сможет создать совместимый аналог
Чтобы уничтожить всех причастных разработчиков нужно уничтожить весьма немаленькое количество людей. Причем конкретных и в совершенно разных географически местах. чтобы при этом еще и все чертежи уничтожить так, чтобы вообще нельзя было восстановить — это нужно уничтожить пол интернета и какое-то количество бумажных распечаток — последнее вообще не представляется возможным. Это что должно произойти чтобы такое в принципе могло случится? Ну и в мире где есть кто-то, для кого такое действие возможно — у нас будут проблемы посерьезнее потери группы инженеров.
При чём тут интернет? Это ведь комерческая информация — разве эти чертежи есть в открытом доступе? Разве только старые версии
Ну значит нужно уничтожить не интернет, а кроме разработчиков еще и тех, у кого есть доступ к серверам. Ну либо сервера. В любом случае случайно такое событие не произойдет до тепловой смерти вселенной, а если кто-то организует такое специально, то нам вряд ли что-то поможет.
Посмотрите пожалуйста на Dolphin или на RPCS3. Это проекты разрабатываемые горсткой энтузиастов в свободное время без исходных документов. Знания размазаны по культуре и восстанавливаются по поведению образцов, от этого никуда не деться.
В этом случае достаточно будет знать, что «такое точно возможно сделать». А значит тысячи энтузиастов ломанутся заполнять внезапно освободившуюся нишу. Человечество заново пробежит вековую историю IT за десятилетие, и кто знает, куда «взлетит» по инерции…
ключевой момент — за десятилетие
возмут люди книжки и начнут изучать с азов, через пару лет появится группа специалистов которая будет востанавливать технологию…
Ну да десятилетие — вместо столетия. Разумеется это будет откат назад, но недолгий и не фатальный. Кроме того многие вещи просто не станут изобретать заново, грубо говоря вместо LPT изобретут сразу USB.
1 и 2 сомнительно.
СССРовсский x86 собственной разработки был или все же в основе интел лежал?
И сколько мелких производителей имеют культуру разработки и как изделий так и технологий, они уже всем готовым скорее пользуются чем собственное разрабатывают.
СССРовсский x86 собственной разработки был или все же в основе интел лежал?
Он был копией — но это было политическое решение. Так же, как и пресловутый Ту-4.
Так же, как и пресловутый Ту-4.

Это Вы зря. Эта машина — самый настоящий реверс-инжиниринг.
Ровно как в случае с К1810ВМ86. Поступил заказ на создание копии — и копию сделали.

Из чего не следует, что ничего своего создать не могут. В конце-концов и Ан-225 и E2K существуют и точно не являются копиями западных аналогов.
Да, все компы мы копировали. Так быстрее врага догонять с меньшими затратами. На заводе Кварц слой за слоем снимали с западных микросхем и потом делали свои побольше, и с 6 ручками, чтобы переносить (юмор такой был тогда).
Прилетят ретролойды, достанут спектрумы, ассемблеры и т.п. и все починят)
Будут люди, которые её будут понимать. Только их будет не так уж много…
Кто то же эту «магию» должен поддерживать на всех уровнях )

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

Да, разрыв будет увеличиваться. И да, будут люди, поддерживающие всё это. Но рано или поздно это кончится. Либо это будет как в "Матрице", когда машины вытеснили людей и заставляют их жить по своим правилам, либо это будет, как тот случай с криптовалютной биржей и холодным кошельком, владелец которого умер.
Это всё к чему. Если (ну вдруг) происходит форс-мажор и людей-"богов" (продолжая образ магии = технологии), которые держали всё на своих двоих, не станет, то мы приедем в тупик цивилизации. Как только мы забудем, если отвлечься от темы технологий, рецепт Кока-Колы, которую знают единицы, то мы никогда не сможем её воспроизвести, лишь пользоваться уже настроенным оборудованием, пока его не придется заменить и забыть программу производства. Так и здесь, не стань пары ключевых людей в Intel, и архитектура процессора для нас — тайна. Тайна, правду о которой мы никогда не узнаем.

То, что для многих «магия», для кого-то просто рутина. Если бы бизнес Intel был так завязан на знания пары людей, то она не протянула бы столько времени. Чтобы защититься от Bus factor люди давно уже применяют разные штуки типа управления знаниями.
Но рано или поздно это кончится.
Совсем не факт. Помимо людей, которые сейчас эту магию умеют есть масса учебных курсов. Из-за роста количества людей которым эту магию нужно чинить — людей владеющих магией тоже становится больше (количественно, не в процентах). Как они могут все внезапно куда-то деться, да еще и всю литературу по теме прихватить — непонятно совершенно. Разве что апокалипсис случится, но там проблемы побольше будут чем непонимание что там под капотом у V8.
Апокалипсиса не надо. Оно встречается постоянно.

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

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

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

Это вы сейчас прям точно в саму природу человека и попали. Сколько тайн хранит не изученный потенциал человеческого мозга. Сколько интересных исследований я вчера почитал по раздвоению личности, после просмотра фильма «стекло». А не потеряли ли мы инструкцию к самим себе. И не это ли хотели нам сказать все предыдущие пророки. Но в силу скудности ума, мы так и не научились читать и слушать. И каждый народ интерпретировал или перевёл это на свой лад.
UFO just landed and posted this here
Сопровождать нужно. Потому что 'работает и не трогай' не очень-то работает, так как внешние условия меняются. И если они поменялись после того, как мы забыли почему ящик что-то делает — то мы не можем даже сказать, нужно ли его выкидывать, или еще можно использовать. И что еще сломается, если мы его все же выкинем. Это как в известном примере с ракетой. Алгоритм перетащили на новую модель, забыв проверить его применимость, в нем произошло переполнение — ой, ракеты больше нет.
Не соглашусь с вами. Проблема есть уже сейчас. Есть такая вещь как утеря технологического наследия. Если коротко — сейчас НЕВОЗМОЖНО воспроизвести многие вещи произведённые 20-40 лет назад.
Вы скажете — а зачем это надо? Ну, к примеру, возобновление производства оружейного плутония. Там всё задокументированно и понятно, для химика, получившего образование в 40-х годах прошлого века. У современного специалиста, фраза " довести концентрацию вещества до 7" вызовет немой вопрос в глазах. Потому что кардинально поменялись методы анализа веществ.
Или совсем простой пример, лет 10 назад надо было слегка модернизировать крупный нефтеперерабатывающий завод в США. Есть некая документация, живы люди, которые её разрабатывали, и методы перегонки вроде не поменялись, вот только реальная схема завода СОВСЕМ не соответствует чертежам. И зачем так было сделано — никто не помнит. Причём видно, что сначала делали по чертежам, а потом переделывали. Результат — небольшая модернизация вылилась в полную перестройку, «с нуля».
Так что это дело не будущего, а настоящего. Мы уже не понимаем что, и почему именно так, делали наши родители.
И управление знаниями не панацея. Бумажная документация — считайте что её нет. Как показывает опыт, она не полная и перепутана. Да и выкидывают её с большим удовольствием. Особенно при банкротстве\ поглощении. Найти что либо в бумажных архивах можно при большой доле везения. Как с нефтеперегонным заводом. Понятно что была документация на все переделки. Вполне вероятно что она даже сохранилась. Вот только ГДЕ?
Вы путаете локальную технологию и глобальную. Вот тот же нефтезавод — он один. Был бы их хотя бы десяток по миру — с документацией было бы гораздо легче и лучше.
Я все еще не понимаю зачем воспроизводить именно прикладные технологии 20-40 летней давности. Они умерли потому что есть что-то более современное, что пришло им на замену. Если где-то решили не модернизироваться и дотянули до момента когда модернизация невозможна, но необходима — ну сами виноваты. В чем трагедия то? Человечество не пострадало, даже на уровне отдельного государства такие случаи редко заметны.
Так что это дело не будущего, а настоящего. Мы уже не понимаем что, и почему именно так, делали наши родители.
Так а нам и не надо. Частный случай провала планирования не в счет — это провал планирования модернизации, а не необходимость восстановления никому больше не нужных тех процессов.
Зайдем с другого края. Американская лунная программа состоялась (или нет) благодоря УНИКАЛЬНОМУ ракетному двигателю ( уникальный по соотношению тяга\собственный вес, там 100 тонн тяги на ОДНУ КАМЕРУ вроде было). Такого двигателя ни у кого не было и сейчас нет ни у кого в мире, включая сами США. Несколько лет назад США пытались снова сделать похожий двигатель, но упёрлись, как и все остальные в пульсации пламени и нестабильность факела.
И возникает вопрос — если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом и не могут воссоздать сейчас?
Ну, его с переменным успехом пытаются. Думаю вы читали, раз интересуетесь, скажем вот это.
если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом
Не использовали потому, что по другим характеристикам не устраивал. В частности отношение тяги к весу лучше и у двигаталей, на которых Союз летает и у пресловутого Falcon-9.

А максимальная мощность одной камеры нужна только на очень тяжёлых ракетах и то не факт, что будет выигрыш: с учётом того, сколько ракете нужно везти топлива небольшой выигрыш по отношению «тяга к массе» может быть легко скомпенсирован проигрышем в экономичности…

Но вообще все эти самые-самые достижения «теряются» обычно потому, что ну очень дорого это: делать самую большую ракету, самый большой самолёт, самый большой экскаватор и прочее. Потому когда, через много лет, снова появляются потребности и деньги — всё с нуля приходится изобретать…
И возникает вопрос — если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом и не могут воссоздать сейчас?
Потому что это не единственные его параметры. Есть еще цена и технологический стек у производителя как минимум. И с включением этих параметров создавать точно такой же двигатель не имеет смысла. А еще есть цель, то есть ее как раз нет. Такой же двигатель банально никому не нужен. Вообще спасибо, это прекрасная каноничная иллюстрация того о чем я говорю — появилась необходимость и сделали лучше на современных технологиях. Да, если бы этот двигатель модернизировали непрерывно с момента его создания, то сейчас не приишлось бы тратить столько времени на создание современного аналога. Но это просто вопрос цены — что нам жалко больше ресурсы на модернизацию того, что не нужно или время на создание более совершенного аналога когда таки станет нужно.
Они умерли потому что есть что-то более современное, что пришло им на замену
Причина не в этом. В случае с СССР после прекращения его существования, было до 800 технологий утрачено. Я не уверен в точности цифры. Но в официальном видео от РосАтома (или кто там главный у нас по реакторам) после развала с трудом нашли человека способного запустить какой-то тип ядерного реактора, и это у государства которое является одним из лидеров в ядерной энергетике. Знания размываются, связующие знания теряются. С ТУ-160 та же история, чуть не проимели титановую сварку в вакууме, но вроде нашлись знатоки. Что-то более современное иногда не приходит.
Нет, несомненно иногда из-за катаклизмов знания реально могут потеряться. Но насколько я понял в предыдущих комментариях речь шла именно о естественном процессе безо всяких катаклизмов. В таком случае если какие-то знания потеряны, значит либо кто-то облажался с планированием, либо они реально были не нужны. Ну и насчет:
Что-то более современное иногда не приходит.
Другие страны же это как-то делают. В РФ не так уж много технологий нужных кому-то еще и которых ни у кого больше нет. Ну может кроме военки, но я тут не силен. Или я ошибаюсь и весь мир страдает без титановой сварки в вакууме?
По поводу страданий всего мира без титановой сварки, я не в курсе. Он в общем то прекрасно существовал и без неё, в те времена когда её ещё не было. Потому тут это и правда вопрос к тем кому это было нужно и почему вдруг оно могло не сохраниться. А вот «естественный процесс» у меня вызывает другие вопросы. Винты ломаются, процессоры выходят из строя, помехи в радиоэфире существуют. Потому называть процесс, из которого исключено что-то что в нём имеется и в нём это что-то случается — «естественным процессом» у меня не получается.
По поводу страданий всего мира без титановой сварки, я не в курсе.
Ну то есть было не очень корректно на примере этого случая говорить что «Что-то более современное иногда не приходит.», так как вы просто не знаете пришло ли или нет. Конкретно в РФ — нет, потому что дешевле было не потерять технологию. Где-то еще — может быть и пришло. Либо где-то еще эта технология и не терялась даже. Я не говорю что вывод неверен, я тольо говорю что для такого вывода у вас не достаточно оснований. Он при этом вполне может быть и верен.

Потому называть процесс, из которого исключено что-то что в нём имеется и в нём это что-то случается — «естественным процессом» у меня не получается.
Не надо смешивать катаклизм — гигантское изменение, катастрофу, с несчастным случаем — плохим, но в целом достаточно рядовым событием, как по эффекту, так и по частоте. Я из естественного процесса исключил только катастрофы. В данном случае — развал сверхдержавы. Можно поговорить о том, где провести границу, но в большинстве случаев это достаточно очевидно. Старый завод который забыл обновиться и у него что-то сломалось — несчастный случай. Развал сверхдержавы — катаклизм.
Потому что многие из более современных специальных технологий не воспроизводимы без специального оборудования и материалов, которые невозможно сделать без других специальных технологий. По ступенькам дойти до нынешнего состояния можно (дошли же), вшагнуть сюда сразу с нуля — невозможно. Максимум — срезать углы и посторонние неоправдавшие себя петли на исторической траектории.
Так а зачем эти технологии воспроизводить то? Насколько я знаю человечеству не нужно выходить на текущий уровень с нуля.
Ну, к примеру, возобновление производства оружейного плутония.

это вы сейчас так хитро тендер в хабр впихнули? или кто та там на верху забыл как плутоний обогащать=)) headhunter не
Не забыли, все записано. Вопрос только — понять. Если вы определяли концентрацию чего-то титрованием при помощи реактива К-1228, то в документации у вас, для быстроты, записана концентрация по этому реактиву. И это нормально, потому что реактива на складе стоит бочка, а если кончится, то позвоним в фирму «Кемикал систерс» и они еще бочку привезут. Вот только склада уже лет 50 нет. А фирма обанкротилась и архивы бесследно исчезли. И как готовить реактив К-1228 никто не знает.

Это образно говоря. Но вполне возможно наткнутся на измерения уникальными приборами, с записью результатов в единицах шкал этих приборов. Или реакции которые тогда шли, а сейчас не идут, потому что степень очистки вещества поменялась, а примеси работали как катализаторы.
> сейчас НЕВОЗМОЖНО воспроизвести многие вещи произведённые 20-40 лет назад

Невозможно сделать это ДЁШЕВО. Если это будет вопрос выживания — воспроизведут. Дорого, за десять тысяч человеко-лет, скажем, но воспроизведут. Да и пример ваш не очень — КНДР, вон, справилась с плутонием.
Пример с нефтезаводом тоже не очень. Построили же! Ну с нуля, но построили. Вот, скажем, в 18 веке не построили бы, вот никак, что с документацией, что без, потому что знаний в культуре не было, и весь завод был непонятная магия.
В одном городе, в 2000-ом, один человек сделал web-gis на MapGuide, а потом эмигрировал. Через 15 лет ко мне обратились люди которых просили это модернизировать, они не понимали как это устроенно. Сайт за это время, пережил несколько перездов и продолжал работать — при том, что никто не понимал как…
та ладно вам, вон выше у кремлеботов химик ядерщик кажется в праотцам эмигрировал=) гугл на запрост о смерти ядерщика подсказывает Владимир Дмитриевич Фёдоров (5 сентября 1930 — 3 июня 2017). У китайских соседей тоже кажется беда. В Пекине 16 января в возрасте 93 лет скончался известный физик-ядерщик, изобретатель китайской водородной бомбы Юй Минь. Как известно, водородная бомба в Китае была создана в 1966 году. При этом Юй Минь смог решить ряд ключевых проблем при ее разработке, за что в дальнейшем его прозвали отцом китайского аналога этого вида оружия массового поражения. К тому же, ученый считается единственным авторитетным китайским специалистом-ядерщиком, который никогда не учился за границей.
Рецепт булата и дамасской стали был в своё время утерян. И что?
Не согласен с пониманием магии(видимо это уже занудство, но все же). Почему не можем понять магию? Есть вещи, которые когда-то были просто волшебством — фантастикой в чьих-то воображениях и мечтах, например, смартфон, сто лет назад это было бы воспринято чистым волшебством(у некоторых людей, не думаю что у всех), телевизор тоже самое. Да я знаю суть на самом деле не в этом и я вообще свернул куда-то в другие дебри. Тем не менее для строгости ради высказался. Магия относительна. Относительна времени и культуры.

Здесь понимание магии как таковой не в том, что она для кого-то — фантастика, а для кого-то — реальность, а в том, что никто её не может объяснить толком. Вот лично я, разбираясь в достаточно простой (на первый взгляд) технологии — техниках рендеринга 3д игр, увяз в тоннах деталей, потонул как раз в той самой "магии" не потому, что это эпоха такая, или я плохой, а потому лишь, что тысячи последовательно возникавших идей создали многоуровневую сложность, пониманием (имею ввиду виду простоту и лёгкость осознания, Simple is better than complex — Python Zen) которой часто жертвуют ради других целей: эффективности, красочности и так далее.
Всё это приводит к тому, что если раньше, будучи энтузиастом, можно было легко покорять геймдев с минимальными знаниями, то сейчас есть шанс вообще не постигнуть этот дар богов.

Вы просто пытаетесь охватить больше чем нужно. Все эти слои абстракции как раз и создавались чтобы не было необходимости понимать все от самого верха до самого низа.
… разделение труда — основа прогресса.
Ну собственно именно об этом я и говорю, да. Вроде бы принципу тысячи лет, буквально, но все равно находятся люди которые его не понимают.
Здесь понимание магии как таковой не в том, что она для кого-то — фантастика, а для кого-то — реальность, а в том, что никто её не может объяснить толком. Вот лично я, разбираясь в достаточно простой (на первый взгляд) технологии — техниках рендеринга 3д игр, увяз в тоннах деталей, потонул как раз в той самой «магии» не потому, что это эпоха такая, или я плохой, а потому лишь, что тысячи последовательно возникавших идей создали многоуровневую сложность, пониманием (имею ввиду виду простоту и лёгкость осознания, Simple is better than complex — Python Zen) которой часто жертвуют ради других целей: эффективности, красочности и так далее.
Всё это приводит к тому, что если раньше, будучи энтузиастом, можно было легко покорять геймдев с минимальными знаниями, то сейчас есть шанс вообще не постигнуть этот дар богов.
С магией точно так же. Просто многое утрачено. инквизиций, церкви. Сколько литературы созжено. Люди боятся того что не понимают.
Техпроцесс основан на самопознаний, на силе разума и чем та там еще. Типа человек может контроливать на атомном уровне силой мысли.
если хоть четверть веб-разработчиков знают и понимают, что под капотом у V8

Если много знать о внутренностях V8, то и код получится заточенный под Google Chrome, а пользователи Firefox расстроятся. Поэтому лучше опираться на стандарт языка, а не на конкретную реализацию.

UFO just landed and posted this here
Вам невероятно повезло, что вы знаете слово «тумбочка» и мебельщик тоже знает слово «тумбочка» и вы друг друга понимаете.

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

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

Рискну вынести мысль-продолжение. Тумбочка говорите?
Ок: тумбочка->спальня/гостиная/кабинет->комната->помещение->дом/завод/соц.объект->сооружение
И таки да, при задаче «нам надо спроектировать сооружение» — вероятность учета уместности тумбочки будет под вопросом.
Однако когда стоит задача "комната" — уже можно дать условные 90%, что все будет совместимо с любой условной тумбочкой.

Чем больше слоев абстракций, тем больше неопределенность в структуре нижних слоев.
Однако человечество справляется. По крайней мере на текущий момент.

UPD: Вспоминаю Sims — там как раз можно «пилить модулями-комнатами» (с тумбочками разумеется).

UPD №2: Смотрю на свою платформу для тестирования — у неё, как и любого сложного продукта есть много слоев абстракций.
На верхнем я просто пишу (утрирую конечно):
— система, вкл.
— система, авторизация
— система, проверить компонент Z
— система, проверить компонент F
— система, проверить компонент H
— система, выкл
Но под капотом,… разнокалиберные сервисы, динамическая балансировка нагрузки, автоматическое выявление неполадок (ага, тулл для тестирования сам себя тоже проверяет), их устранение (узкий спектр, но тем не менее), гибкое конфигурирование (частично на лету, самостоятельное). Система за собой даже тестовую среду может подчистить (убирать за собой, для возможности протестировать «продакшн»).
Т.е. в недрах крутится просто адская сущность, в которой без бутылки порой и не разберешься — блок-схемы в компе (или на бумаге) обязательны для возможности удержать в голове общую структуру.
Но это весьма надежная молотилка.

И все это управляет еще одним набором пластов абстракций, заключенных в webDriver.
Люди говорят — «сделай карту» и не могут объяснить, что они хотят…
выбрал PHP — слил жизнь в унитаз. Выбрал Go — стал тупицей.

Выбрал .net — не спишь по ночам, пытаясь восстановить связь с реальностью.


Шутка. Интересная публикация (y)

А я php не выбирал. Он выбрал меня :(
нет, поглотить и растворить в себе во славу Расмуса Лердорфа
Кому нужен много контроля и низкий уровень — пишут на С.
Кому нужен максимальный контроль — на asm.
Единственная полу-успешная попытка явно перестать отвечать за код умерла с архитектурой Intanium :)
А абстракции… То, что делают команды людей слишком сложно, чтоб обходиться без них — попробуйте себе представить, что происходит в каком-нибудь современном лайнере целиком или хотя бы в процессоре — в деталях и без абстракций?
А в каком месте у вас в Си есть контроль? Есть жалкая иллюзия, что может быть, то, что вы написали — не undefined behaviour. Потому что если это UB — то компилятор пишет за вас. Что-то.
UFO just landed and posted this here
Это не отменяет иллюзии, точнее того, как больно она рассыпается.

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

… да и они знают только часть общей картины.
FPGA -> процессор со своим набором команд, никаких сторонних ISA. Никаких кэшей. Никакого спекулятивного исполнения или суперскаляра. VLIW — это все, что мы можем позволить для ускорения. Ладно, еще во входном буфере храним считанные данные, ибо принципы временной и пространственной локальности все же ускоряют работу, не нарушая детерминированность. Хотя нет, он неизменно (низменно) выродится в кэш при попытках ускориться, поскольку дальше разрастется и пойдут стратегии вытеснения данных из него — на фиг такие искушения, давим в зародыше.
А теперь начинаем ме-е-едленно подниматься наверх. Свой ассемблер. Свой компилятор, который переставляет команды для оптимизации загрузки функциональных устройство стрррого по заданному алгоритму. Линукс порт. Busybox. Едва-едва дышащие (на тысячедолларовой FPGA) vi и mc. Текстовый браузер. И запоздалое понимание: на кой черт я безвозвратно потратил десять лет жизни — чтобы убедиться в том, что я точно понимаю, что под капотом?
А потом пришли микрокоды и команда add вполне себе могла перестать быть передачей двух операндов на сумматор… Если же посмотреть на что-то из AVX2 инструкций, то тут уже становится совершенно непонятным, как оно работает на уровне RTL, и тем более ниже, на уровне транзисторов.
А зачем это «как»? Есть спецификация, вы при желании сами можете построить по ней чип на HDL. Да, возможно вам понадобится десяток человеко-лет на особенно сложные, и работать они будут небыстро, но ведь будут.
UFO just landed and posted this here
Достаточно вспомнить быстрый обратный квадратный корень Кармака и Silicon Graphics, который явно использовал трюк, который является UB, но как раз-таки из-за того, что автор хорошо понимал, каким оно получится на низком уровне в конкретном случае, оно работает.
Тот трюк вызывал UB не из-за «непонимания чего-то на низком уровне», а тупо из-за каламбура типизации. Меняете его на bit_cast — и всё, никакого UB.
Это смотря с какой точки зрения смотреть: с точки зрения asm — да, иллюзия контроля, а с точки зрения аналитика больших данных, который пишет код на Scala, который выполняется на Spark, который получает виртуальные контейнеры от YARN (при этом каждый процесс на своей JVM), взаимодействует с Hadoop и работает с виртуальной памятью и не менее виртуальными ядрами через вызовы к ОС — у вас дикая уймища контроля!
PS только сейчас подумал, что Глушковская ОГАС сейчас занимает 1 серверную стойку и стоит в каждом приличном банке, как минимум — 1.
Кому нужен много контроля и низкий уровень — пишут на С.
Кому нужен максимальный контроль — на asm.

<сарказм>… а кому нужно ещё больше контроля, пишут на Scala.</сарказм> Я, конечно, понимаю, что это просто DSL, но забавно всё-таки, что функциональный язык оказался в чём-то ближе к железу, чем asm (да, я знаю, что можно "писать процессоры" хоть на Python).

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

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

Был. В 50х, когда писали программы машинными словами ( производительность — 3-4 машслова в день) и в любой момент могли по индикаторам посмотреть состояние регистров.
Ну, не до такой степени же. Талантливый инженер мог за день написать целую программу, которая была способна что-то посчитать.

… До индикаторов был осцилограф, который точечками биты показывал.
www.youtube.com/watch?v=nc2q4OOK6K8

В 50х еще даже мои родители не родились. Я боюсь, что автор поста, скорее всего, тоже.

От чего же?
Я тоже из того времени и начинал писать на Урал-1, где все переменные должны были быть от -1 до 1, а в системе команд не было циклов и переходов с возвратом(вызов подпрограмм). Пришлось пройти весь путь от машинных команд через Алгамс, Кобол, PL/1, C, C++, Java к C#, WPF со множественными ответвлениями в разные стороны.
И ЯП не главное. Кроме языков есть методологии и технологии: модульность, структурное программирование, HIPO, Варнье, Джексон, ООП и др.
Пройденный путь помогает понять — почему и куда движется программирование.
UFO just landed and posted this here
Я начинал в 1975. Алгол-60. Примерно в середине 80-х состояние регистров ЕС-1061 — вполне мог, и посмотреть, и останов поставить, в общем — отладка с пульта в полный рост, хотя писал уже по большей части на REXX, который был весьма высокого уровня язык даже по сегодняшним меркам.

3-4 слова в день — конечно перебор.
50. Алгол — только в мечтах.
Есть БЭСМ -1, у которого всего ничего памяти, поэтому — программирование в машинных словах:
Вот он, полный контроль
Система команд: трёх-адресная. Количество разрядов для кода команды — 39. Код операции — 6 разрядов; коды адресов — 3 указателя по 11 разрядов каждый, что позволяло адресовать 2048 ячеек памяти для операндов и результата. Регистры общего назначения отсутствуют.В систему команд машины входят 9 арифметических операций, 8 операций передач кодов, 6 логических операций, 9 операций управления. Машина имеет общее поле памяти для команд и чисел (Архитектура фон Неймана) — 2047 39-разрядных ячеек (ячейка с номером 0 всегда возвращает машинный нуль). Специальный бит в поле кода команд позволял отключить нормализацию с плавающей точкой и выполнять адресную арифметику. При написании программ для БЭСМ-1 широко применялась техника само-модифицирующегося кода, когда напрямую модифицировалась адресные части команд для доступа к массивам.
В конце 80х пришлось программировать точно так же, поднимать стек с ноля. Производительность была намного больше 3-4 слов в день. Вы каких-то страшилок начитались. Пишешь на ассемблере, вручную транслируешь в адресное пространство, вручную набираешь с бумажки в консоль (да, кнопочками). В день можно 300-500 комманд написать. Не каждый день конечно, а один день, потому что хватает написать только ввод-вывод с перфы например, а потом уже набор идет быстрее, а там и монитор, и магнитная лента, и интерпретатор, и ассемблер.
В принципе, с этими временами можно и сейчас столкнуться. Например, на военной кафедре в 2000-х годах я, так сказать, программировал на машинах, гораздо менее абстрактных, чем те, на которых программировала моя бабушка в 1970. У неё уже были Алгол, Фортран и какой-то советский аналог ПЛ/1, ввод осуществлялся удобными перфокартами, вывод тоже печатался на бумаге. Мы же двадцать пять лет спустя вводили данные тумблерами по 1-2 команды, вывод шёл лампочками-индикаторами. Настоятельно рекомендовалось, помимо машинных команд, разбираться и в микрооперациях.

Ой. А расскажите, что за машина, пожалуйста! Если не секрет.

Ого, то есть оно ещё десять лет назад в строю было?
Совершенно спокойно в своё время на лабах писались программы на сях, которые не менее спокойно руками транслировались в ассемблер, а из него — в те самые машкоды.
Которые да, руками забивались в машинку с 486 процессором и затем успешно исполнялись.
И полный цикл разработки-внедрения какого-нибудь метода Сименса занимал две сдвоенные пары.
А вот дебаг, это да, страшно было.
Вот только в 486 машкоды уже не соответсвовали тому что внутри процессора происходит, внутри работа уже шла в микро операциях.
Не надо только пугать народ, а? μopsы — это Pentium Pro. Даже Pentium напрямую все инструкции исполнял…
«Вавилон 17» вспомнился мне.
выбрал PHP — слил жизнь в унитаз. Выбрал Go — стал тупицей

Доктор, а если я выбрал HDL, я ещё не совсем безнадёжен?
Пока вы не включили в свой проект софт-ядро какого-нить ARM/MIPS — нет, ещё не безнадежны =)
На мой взгляд, автор сгущает краски.

1. Потеря контроля из-за делегирования и абстрагирования — основа человеческой цивилизации. Думаете, проектировщик корпуса нового спортивного автомобиля понимает, как работает его двигатель? Или всю глубину математического аппарата под моделированием аэродинамических характеристик? Думаете, врач знает, как работает МРТ, на основе которого он ставит диагнозы, определяющие чью-то жизнь? Мы все миримся с этим, потому что другого способа реализовывать сложные вещи и процессы у нас нет.

2. Увеличение толщины слоя абстракций в ЯП, как мне кажется, сильно преувеличено. Да поправят меня люди, чей опыт побольше моего и исчисляется десятилетиями, но по моим ощущениям за последние пару-тройку десятков лет толщина этого самого слоя не так чтобы особо выросла. Языки стали более зрелыми, да, инструменты стали более мощными. Но концептуально изменилось немного. Изучая устройство V8 я часто обнаруживал, что многие его ключевые фичи изобретены в 60-x – 80-x авторами какого-нибудь Lisp или Self. Выше упомянули Spectre — так и спекулятивному выполнению уже лет 30 как.

Но финальная идея, что язык значительно определяет сознание верная. Выход на мой взгляд простой — стараться изучать концепции, а не языки, смотреть шире. Тогда ставка на «неправильный» язык не будет критична.
  1. Увеличение толщины слоя абстракций в ЯП, как мне кажется, сильно преувеличено. Да поправят меня люди, чей опыт побольше моего и исчисляется десятилетиями, но по моим ощущениям за последние пару-тройку десятков лет толщина этого самого слоя не так чтобы особо выросла. Языки стали более зрелыми, да, инструменты стали более мощными. Но концептуально изменилось немного. Изучая устройство V8 я часто обнаруживал, что многие его ключевые фичи изобретены в 60-x – 80-x авторами какого-нибудь Lisp или Self. Выше упомянули Spectre — так и спекулятивному выполнению уже лет 30 как.

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

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

Даже древнебородатый (не в обиду) C++ сегодня достаточно неплохо переносится между платформами. Понятно, что с перекомпиляцией; понятно, что нужно учитывать ряд ограничений (иначе и никак). Но тем не менее вы вполне можете писать кросс-платформенный код на С++ — имея при этом те самые «zero-cost abstractions».
UFO just landed and posted this here
Ага. Я просто это к тому, что для достижения независимости от железа не так чтобы особо сильно были нужны всякие Python и JS.

Так с++ собирается под разные платформы, а пайтон и джаваскрипт запускаются на разных платформах.

так пайтон и жаваскрипт — интерпретируемые, а интерпретаторы на том же c\c++ и написаны, не?
вот только платформ на которых можно запустить python/js в разы меньше.
вот такая вот «кросс-платформенность»…
А это как раз принципиальная разница в подходах. C/C++ не скрывают от вас железо. Она запрещают вам использовать некоторые конструкции (те, которые непереносимы). То есть поддержка переносимости программ возлагается на программиста.

А вот C#/Java (в меньшей степени Python/JS) — как раз ради этого и созданы: вам не нужно думать на каком CPU ваша программа запускается — если она работает у вас на десктопе, то и на телефоне запустится… разумеется такой подход ограничивается количество доступных платформ гораздо сильнее: вы не можете (как в C/C++) сказать «если ваша платформа это умеет — то и отлично, а если нет — то ошибка компиляции» и потом обложить это место #ifdef'ами. Вам нужно выбрать некоторое множество фич и обеспечить их работу на всех платформах…
UFO just landed and posted this here
Я это все к тому, что вместо стандартизации, мы продолжаем решать проблему не на той стороне, добавляя ненужные абстракции.

Мне кажется, что никогда такого не будет, потому что слишком много разных кейсов и для них нужны слишком разные стандарты. Даже тот же "стандартизированный" sql не очень то стандартизирован. Да что там, даже tcp/ip стек в каждом месте имеет свои приколы.

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

И чем абстрактнее становится язык, тем сильнее из твоего мышления вымывается его реальное назначение — контролировать электричество в железе.

Не-а. Реальное назначение — это решение задачи. Например, «показать пользователю иконку состояния ВПН соединения». Это — задача, а не манипуляция отдельными пикселями на экране. И если ты можешь решить эту задачу проще, то и чудно.
А в результате такого уровня абстракций мы имеем требования вида «два ядра два ведрагига игровая видеокарта» для какой-то смотрелки картинок, функционал которой особо с 90ых годов никуда не сдвинулся. И всёравно все эти абстракции порой нормально не работают(пинок в сторону Java — ну почему мне требуется держать кучу версий JVM, почему софт не может работать в одной последней).

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

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

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


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

Понятно, что процессор сам себя не разработает.
Я за то, что пользователи этого железа (а бытовые разработчики железо именно используют,
а не разрабатывают) не контроллируют электричество в железе. Оно на уровне абстрактных вещей формулирует другие, более высокоабстрактные вещи. И так далее. Все это в конечном итоге для того, чтобы кто-то смог действиями на экране заказать пиццу или посмотреть кино.
И это прекрасно — я вместо того, чтобы тратить время на приготовление пиццы, займусь теми вещами, которые умею делать. А пиццу пусть приготовят те, кому это выгоднее делать.
Но, по крайней мере, в том же Фотошопе до сих пор не появилась кнопка «Сделать красиво» (самый высший уровень абстракции!), про которую шутят начиная с появления первых версий этого графического редактора.
Я знал людей, котрые сами пекли хлеб дома, довольно вкусный… там было шесть взрослых сестёр
и это в действительности ведет к прогрессу
Проблема только в том, что это прогресс для программиста, не для пользователя. Для пользователя, как уже здесь писали, с 90-2000х мало что принципиально поменялось. Да, кое-что стало слегка красивее. Но те же операционки с приблизительно XP для пользователя почти не поменялись. Браузеры тоже. Да, они стали обрабатывать огромные страницы по несколько мегабайт, но чем гмейл из двухтысячных хуже современного? дизайн слегка поменялся, он стал весить раз в 10 больше. по возможностям на фронтэнде всё примерно то же.
Мобильные устройства, например, из устройства для звонков отобрали перевенство у персональных компьютеров. У меня в смарт часах больше оперативки, чем в первом компе.
А персональные компьютеры обзавелись, например, поддержкой HDR и Hairworks. Процессор позволяет моделировать сложнейшие модели на ноутбуках в килограмм весом. Хорошую звуковую карту для проигрывания HI FI музыки можно уже не покупать — это все давно встроено в наушники.
Само собой, если не запускать ничего сложнее почтового клиента, блокнота, консоли и третьих героев, можно все это не заметить.
Но утверждать, что ничего не изменилось…
По железу изменения есть, ок. Но обсуждаем же софт? По софту изменения минимальные. Скайп, например, стал только хуже 'благодаря' новомодному Электрону в том числе.
Мобильником примерно таким, как я пользуюсь сейчас (Samsung J1 16), я пользовался уже 10+ лет назад (Motorola A925).
уведомление на браслет, музыку в беспроводные наушники и магнитолу, сверхскоростной интернет с возможностью просмотра fullHD видео на 6 дюймовом смартфоне — ну да, почти тоже самое.
по софту — вымирание любительской фототехники как класса (мобильник с ии фильтрами на борту), полноценные мобильные клиенты для соцсетей (покажите мне приложение с возможностями мобильного вКонтакте 10 лет назад), невероятно интуитивное и удобное яндекс такси, голосовое распознавание команд в мобильнике с набором текста — тоже было 10 лет назад?
Десять лет назад голосовое распознавание команд в мобильниках было. А вот сейчас его уже нет. Перекочевало в облака (точнее на чужие компьютеры).

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

По крайней мере, фразы типа «ОК, Гугл!» и «Слушай, Алиса!» распознаются в самом смартфоне, а после запуска распознавания речи далее все идет через облако.

Одна фиксированная фраза.
А некоторые кнопочники недурственно распознавали имена из телефонной книги без обучения.

Всё развивается по-спирали… Во времена молодости был такой Clarion, которые позволял писать программы, щелкая мышкой по менюшкам, и программы работали. Но проблема была в том, что сделать могли только те вещи, до которых додумался разработчик языка, и даже небольшие «хочувоттак» приводили к углубленному копанию, подключению внешних библиотек и прочее.
Так что думаю, не придёт уровень «сделай вот такую хрень», потому как обязательно потребуется «сделай почти такую же хрень, но с перламутровыми пуговицами». И если разработчик абстракции не предусмотрел такой возможности, то целиком вся абстракция оказывается непригодной и придётся спускаться на уровень ниже.
О да! Clarion тот еще подарок был. И мышкой там щёлкалось ровно до тех пор, пока не полез руками в код. Основная его беда была в невозможности построить проект по написанному коду. Раз что-то в коде исправил, и всё, про щелканье по менюшкам можно забыть.
Рад встретить человека, который общался с этим языком.
Clarion тот еще подарок был. И мышкой там щёлкалось ровно до тех пор, пока не полез руками в код.
Верно только для CPD 2.X/1.X, уже с CDD 3.X решено templates
«Язык определяет сознание». (и к этому, до кучи, ещё фильм «Прибытие»).

По поводу «через какое то время» — всё станет очень просто:
1. Сначала абстракция достигнет возможности не особо подготовленных пользователей писать «программы» — последовательности действий. Программа! Возьми рубли, преврати их в доллары и просуммируй за 100 лет по каждому клиенту. Или — подсоединись к Вконтакте и слей туда все мои фото по АПИ.
Программа ещё будет иметь достаточно много ограничений, но она будет уметь описывать в каких допустимых формах пользователь может ей сказать что хочет.
2. Пользователь сможет говорить своим языком в какой последовательности что и как надо сделать. Программа! Возьми вон тот столбец со значком Р и посчитай оборот за последний век.
3. Пользователь будет указывать что ему надо — программа сама построит алгоритм выполнения. Программа! Посчитай обороты для моего отчёта!

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

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

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

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

… но наши дети точно будут уже совсем другими.
«Язык определяет сознание». (и к этому, до кучи, ещё фильм «Прибытие»).
Если изучать языкознание не по фильмам, то внезапно всё оказывается совсем не так.
Вот тут лингвист кратко, но достаточно понятно разъясняет этот вопрос
Мягкая версия гипотезы Сепира-Уорфа, тем не менее, находит немало экспериментальных подтверждений.
По моей ссылке Максим Кронгауз про это тоже рассказывает, если что.
Для меня это была интересная идея, а не прикладное знание )

Но за ссылку спасибо )
Я надеюсь дожить до того дня когда в Фотошопе-лайт будет всего одна кнопка «Сделать хорошо!» Всё к тому идёт…
Простого, неподготовленного человека.

Как показывает практика, простой, неподготовленный человек не умеет делать то, что вы описали в п. 1-3.

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



Думал, что ну вот теперь-то точно программирование станет доступным всем, но подумал и согласен с комментатором выше — здесь всё ещё есть декомпозиция задачи, а обычному человеку легче сказать «сделай мне Space Invaders», чем разобраться из чего состоит игра, чтобы командовать компьютеру «создай пулялку, создай пулю, назначь перемещение пулялки на стрелки, назначь перемещение пульки верх при нажатии стрелки верх и пусть она остановится на расстоянии в N пикселей...»

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

Есть ещё один (тьюринг-полный) способ визуального программирования :D


UFO just landed and posted this here
Меня в этом абзаце скорее наоборот, заинтересовал русский. :)
Лично у меня (носителя русского языка с рождения), фраза «случилась херня» не вызывает ощущения что «херня виновата»; может, я как-то неправильно её понимаю?..
Имеется в виду, что она как бы случилась сама по себе, без участия (и, соответственно, ответственности) говорящего.
Ну это понятно, да. Но «без ответственности говорящего» != «херня виновата».
Я изначальную фразу (без уточнений, что именно случилось и кто виноват) воспринимаю скорее как форс-мажор, обстоятельства непреодолимой силы.
Я вспоминаю 2 формы, не уверен какую имел в виду автор.
Вариант «lo paso» — оно произошло. И, например, «las llaves se calleron» — ключи уронились, типо сами.
Типичное промышленное программирование. Сначала перешли от Паскаля где всё расписано словами к Си, где всё расписано закорючками. Потом стали пришлёпывать к нему кучу надстроек, чтобы было «более понятно».

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

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

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

за 6 лет разбирал комп 2 раза, один раз термопасту поменял (перепал тюбик, грех было не воспользоваться), и год назад воткнул видеокарту пободрее, чтобы нормально в Doom загамать. Что я делаю не так?
Ну почему же «не так»? Вы просто работаете с ним как опытный пользователь, которому не нужно ничего делать с железом, чтобы всё работало, а достаточно грамотно оперировать софтом.
Опытность видимо — это пользоваться лицензионным ПО и автообновлениями Windows.

Но ведь это и правда так. Всяким околокрасногоазием болеют в старшей школе и универе. Потом люди вырастают (не все, конечно) ака "приобретают опыт" ну и… лицензионное ПО, автообновления windows :)

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

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

2) Что произойдет, если всё же перестать тупо следовать прописанным шаблонам? Тормоза исчезнут?
Да и сейчас не очень-то нормально попользуешься — народ покупает компьютер/планшет с более худшей начинкой потому, что отзывы лучше, а не потому, что более лучшими характеристиками( к примеру 4Gb оперативки против двух).

Реальна волновая функция. До этого "электричества", которое хочет контролировать автор, ещё пара слоев абстракций. И между электричеством и процессорной командой — ещё парочка.


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


Хочешь всегда работать на уровне машинных инструкций? Вотсап не сделаешь, потому что сложность будет неподъемная. Каждый слой абстракции нужен для упрощения. Работаешь с интерфейсом, а что под капотом — не смотришь, кроме самых важных случаев.

Нет ничего невозможного в создании мессенджера на уровне машинных команд. В конце концов, на ассемблере полно доступных библиотек и сетевых, и криптографических. Будет ли разработка приятной, результат надежным, а программа удобной — совсем другой вопрос.
«Сделай программу которой сможет пользоватся даже дурак — и только дурак захочет ей пользоватся»
Один из законов Мэрфи.
Законы Мерфи — абстракция.

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

результат надежным, а программа удобной

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


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

И вот уже у вас сразу предложение использовать абстракции. Об этом и речь — без них никак :).

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

Реальна волновая функция.

А мне показалось, что она на таком высоком уровне абстракции, что Реактам на Электроне и не приснится.
UFO just landed and posted this here
> И чем абстрактнее становится язык, тем сильнее из твоего мышления вымывается его реальная природа — контролировать электричество в железе.

Так вот ты какой, смысл жизни!

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


В турецком и персидском языке местоимения «он» и «она» не различаются, и где там это ваше гендерное равенство?
Автор явно что-то напутал с языками в этом абзаце. Следствие рефакторинга, наверное.
> Они бы не офигели от нашего количества абстракций ради абстракций?

Вот ссылкa на одну из книг по работe с языком программирования при формировании решения задачи 1984 года: Л.Броуди «Cпособ мышления — Форт язык и философия для решения задач» archive.org/details/Broudie2

P.S. Но, боюсь тогда придётся признать, что мы со своим мышлением не «универсальные винтики» в глазах менеджеров при создании ПО.

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

Есть, нпр., пневматические вычислительные машины. Так что электричество совсем не обязательно.

В свете сказанного можно заключить, что беда не в высоком, а в слишком низком уровне абстракций. Практики, владеющие многими абстрактными технологиями, предназначенными для конкретных задач, не видят леса, т.е. обобщающих абстракций, на которых базируется методология научного подхода. Столкновение с методологией науки у людей неискушенных вызывает ложное чувство потери контроля.
Лингвисты давно установили что чем сложнее человеческое общество, тем абстрактней его язык. У эскимосов есть несколько десятков слов, описывающих разновидности снега. Но вот слова «снег» у них в языке нет. Сказать -«выпал снег» эскимос не может. Может сказать «выпал тяжёлый мокрый снег» или нечто наподобии. Но и только.
У австралийских бушменов в языке нет слова «дерево». Нет, названия для каждого вида деревьев в языке есть. Но сказать — «на холме 3 дерева» они не могут, только «на холме 3 акации» к примеру.
Так что уровни абстрагирования в живом языке от языков програмирования не сильно отличаются.
Меня вот больше удивляет, что каждый год появляются новые языки программирования и люди каждый раз заново пишут для них стандартную библиотеку. Все то же самое, что было уже миллион раз написано.
В лучшем случае — пишут обертки для уже существующих библиотек.

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

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

И в результате мой супер-пупер-абстрактный платформонезависимый код начинает обрастать условной компиляцией чтобы учитывать все эти особенности. Какое уж там «сделай табуретку».
Новый язык программирования обычно подразумевает некие относительно новые абстракции и подходы к программированию, поэтому взять стандартную библиотеку от другого языка будет несколько некошерно.
Теоретически — да. Практически, повторов довольно много — почти вся математика, работа со строками, разбор аргументов командной строки… И GUI раз за разом изобретают заново, да все никак не изобретут так, чтоб кроссплатформенно вышел (Electron'ы, молчать!).

Вроде бы изобрели Qt, который работает везде, где вообще есть экран.

Да, только окна выглядят по-разному, шрифты выглядят по-разному и т.д. Есть, короче говоря, нюансики.
Это же хорошо — у каждой платформы должен быть свой Look-n-feel, и все фреймворки должны его слушаться. Хотите везде одинаковых квадратно-серых виджетов — получите tk.
Я полагаю, что это зависит от конкретного приложения. Кому хорошо, а кому и не очень.
Но вообще, я говорил немного не об этом, а о том, что в каждом новом языке заново переизобретают стандартную библиотеку GUI в частности.
Биндинги к Qt встречаются примерно так же часто, как и обертки над сишными вызовами — т.е. часто, но все равно требуют большого количества оберточного бойлерплейта.
Ну вот например в языках без ООПэ как гуй сделать правильно это большой вопрос. Никаких «все уже украдено до нас» нет.
Глобализация невозможна без всеобщей перезагрузки.
Где-то я потерял одну очень хорошую статью про три культуры в программировании. Людям из первой интересно программирование с более математической стороны, им важно чтобы код был красив (в математическом смысле) и корректен. Вторым интересен сам процесс вычисления и эффективность использования ресурсов. Ну а третьи просто хотят решать практические задачи.

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

У людей же из второй культуры, начиная с 70-х, дела, похоже, идут всё хуже и хуже. Посочувствуем же им.
Ну не знаю, я не контролирую электричество в железе (кремнии?), я контролирую изменение информации. Ведь программирование как раз про это, превращение одной информации в другую, ее хранение и контроль. Это нулевой уровень абстракции. А бегают там электроны по железу или фотоны по кристаллам меня не волнует пока проблема/задача не опускается на уровень железа (или я не опускаю ее туда). Потому что «железо» это просто еще один аспект, а не «основа всего». Это в стороне а не внизу. Завтра вы перенесете софт на другой сервер, это же не значит что его нужно полностью переписывать?

ЯП это инструмент. Само собой он влияет на носителя. Как и любой инструмент. Если в руках молоток то все вокруг кажется гвоздями. Но мышление первично, пусть и меняется под действием привычек, задач, используемого инструмента. Я вот про это «Это не гаечный ключ у тебя в гараже — это кусок твоего сознания. », это перебор. Если это действительно так, то это серьезная профессиональная деформация. Причем с привязкой к области и языку. Встречал не раз что-то подобное, обычно это была зависимость от инструментов уровня фреймворка, люди мыслили не задачей, информацией, другими критериями вроде надежности, масштабируемости, сложности, гибкости, а следует ли код духу фреймворка и мануалам/рекомендациям или нет, вот когда это было уже в ущерб задаче и другим важным параметрам — то это мешало. Фреймворк первичный у них был, а не всего лишь инструмент. С языком тоже часто встречал, но не настолько, все же любой ЯП достаточно гибок а мануалов как «истинно правильно» на нем делать не так уж и много.

Абстракции это нормально, даже хорошо. Абстракция это как модель, отражает только нужные нам качества чего-то. Их ограниченное количество и все нужные, и это дает настоящий контроль. Если вы управляете автомобилем то вы управляете с помощью руля и педалей. Где-то там работает двигатель по своему циклу карно, что-то подсчитывает и контролирует бортовой компьютер, и где-то датчик в бензобаке ждет своего часа. Вы смотрите на панель и крутите руль, а не контролируете каждое колесо отдельным рычагом, наблюдая работу двигателя через прозрачный кожух в прозрачных цилиндрах и периодически на ходу опускаете щуп в бензобак.
Вам все это не нужно, да это даст больший контроль (на самом деле нет), но это не нужный в данный момент контроль, он только мешает, забирает время, отвлекает, размывает фокус, и котролируя каждое колесо вы меньше внимания сможете потратить на дорогу. Контроль потребуется когда вы услышите странный стук а потом машина заглохнет. Вот тогда вы откроете капот. Или потащите автомобиль в автосервис.
Да мы пользователи. Пользователи процессора, файловой системы, пользователи библиотек и third-party закрытых инструментов, пользователи API внешних сервисов. Мы пользователи черных ящиков. Эти ящики вокруг нас. При разработке мы фокусируемся на том что нам нужно сделать, при этом «пользуясь» кучей инструментов о которых мы знаем крайне мало, только то что нам нужно. И если мы будем заглядывать постоянно к каждой машине под капот, просто чтобы сохранить имитацию (да именно имитацию) контроля — мы не сможем заниматься основной задачей. Мы заглядываем под капот, вскрываем ящик только тогда когда понимаем что проблема именно в этом ящике. Или не вскрываем а меняем. И это нормально. Потому что мы знаем что вот этот черный ящик с надписью «процессор» выполняет то-то и то-то, мы знаем что он делает, нам не нужно знать как, и тогда черный ящик можно спокойно заменить на другой с тем же набором свойств. Сервис на другой. Библиотеку обновить. Это отлично, это дает гибкость и стабильность. И все благодаря абстракциям.

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

То что компьютер все больше становится черным ящиком и для нас, программистов, это нормально, это специализация. Это непривычно, нам немного стыдно признавать что мы уже ничерта не понимаем в деталях в работе процессора и вряд ли сможем починить материнскую плату если что-то пойдет не так, не говоря уже о том что не спаяем компьютер в гараже из набора простейших деталек и чипов из ближайшего магазина радиотехники. Но это нормально, суммарно контроль не утерян, он просто стал глубже и разделился на десятки специализаций, ни у одного человека уже не хватит знаний чтобы быть экспертом во всем что связано с компьютерами. Обьем «эксперта» во всей области давно уже перевалил за 10 тысяч часов и исчисляется миллионами часов, и скорость роста знаний превышает скорость освоения, а сложность растет. Один человек просто не способен разобратся во всей области. Он не будет успевать поддерживать актуальный уровень. И даже опуститься вниз до процессора по отдельной области. Даже поддерживать 100% информированность по всем связанным с узкой областью инструментов не получиться, даже популярных, не то что опускаться вниз.
Будте хороши на одном, своем уровне, и своей области, пусть другие занимаются остальными, каждый своей.

Кстати вот эта практика, которую вы описали, с мультиязычностью меня немного удивила, имхо, плохо это. На простых задачах и проектах в принципе нормально, но на сложных начинают тащить привычки и принципы одного языка в другой, и такой плохоподдержвиваемый ад со временем получается…
Если язык не важен — почему их так много? Разве что действительно одну и ту же библиотеку на разных языках, для пользователей того же API. Ну это редкость и достаточно законченная задача, там если что и «выбросить все и написать заново» не страшно.

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

Извиняюсь за многобукв, во всем виноваты абстракции, человеческий язык слишком несовершенен, и из-за этого приходиться использовать дополнительные слои в виде тех же примеров и аналогий, чтобы передать изначальную мысль с минимумом искажений внутренними фильтрами наших черепушек. Вот бы где нам действительно «языки низкого уровня» пригодились бы. Когда там уже мыслеречь допилят и общение образами?
UFO just landed and posted this here
человеческий язык слишком несовершенен, и из-за этого приходиться использовать дополнительные слои в виде тех же примеров и аналогий, чтобы передать изначальную мысль с минимумом искажений внутренними фильтрами наших черепушек. Вот бы где нам действительно «языки низкого уровня» пригодились бы. Когда там уже мыслеречь допилят и общение образами?

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


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

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


На счет мыслеречи вспоминается следующий отрывок (не дословно; даже интересно, на сколько сломанным получился телефон) из какого-то довольно известного фантастического произведения (ни автора, ни названия к сожалению не вспомню уже за давностью лет, а нагуглить с первого раза не удалось):

Раздался хлопок и перед нами предстал взъерошенный человек с сигарой во рту, в помятом костюме с криво завязанным галстуком и чемоданом в руке.
— (Существо, раздраженный голос) Ужасный, ужасный день!
Нервная дрожь, попытка поджечь сигару.
— (ГГ) Эти создания курят?
— (Кто-то) Конечно же нет. У данных существ совершенно другая физиология, куча щупалец и т.д. Рядом с планетой Z взорвалась сверхновая, и у них было только 5 секунд чтобы покинуть дом с самыми необходимыми вещами. Переводчик транслирует действительность, речь в базовый галактический язык, а затем в понятные вам образы и конструкции. Если каких-то понятий в вашем языке нет — строятся аналогии или отрывок просто пропускается.

Если вспомните — пожалуйста, дайте ссылку, возможно захочу почитать эту фантастику )

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

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

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

Вторая категория — высокооплачиваемые спецы, которые идут впереди планеты всей, их зарплаты в зависимости от страны в диапазоне 100-300К, они придумывают разные языки, фреймворки, платформы и не дают заскучать первой категории.

как понимаю вы из второй категории?

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

Ну конечно, вы ещё сомневаетесь?))

Вот только вы денежный вопрос слегка перепутали. Бывает.
Первой категории платят деньги. Они бизнес-задачи решают, а бизнес им за это деньги платит. Конечно, клепателям формочек платят слегка меньше, но вот изобретателям формочек (для последующего клепания) — уже нормально так.
Вторая категория, творцы и маги — иногда не получают примерно вообще ничего. В лучшем случае — пока кто-нибудь из первой категории не прочувствует мощи очередной магии, и не начнёт заносить. А в худшем — творцы и маги просто работают в первой категории, а магию творят — во внерабочее время. И подавляющее большинство этой магии (как впрочем и любых других вещей) — не взлетает вообще никак.
Был фантастический рассказ — старый программист что-то клепает, а искусственный интеллект всё не может понять и повторяет — «ты мне объясни что ты хочешь, я сам сделаю быстрее и лучше, так как ты давно никто не делает» и т.д. Конец рассказа — вирус запущен, ИИ понял что ему конец, но сделать уже ничего не может.

Насчёт творцов. В Perl два виде массивов — просто упорядоченные списка, и хэши. И всё. Тривиальный Borland С++, как помню, начинался с десятка разных массивов-коллекций-списков разной степени навороченности и километровой наследуемости. Программисты-творцы решили что Perl слишком простой. Ну и получили то что получили — вместо простого понятного языка сделали кучку «магии», с которой теперь приходится справляться. Желание творить привело к появлению тварей.
Был фантастический рассказ — старый программист что-то клепает, а искусственный интеллект всё не может понять и повторяет — «ты мне объясни что ты хочешь, я сам сделаю быстрее и лучше, так как ты давно никто не делает» и т.д. Конец рассказа — вирус запущен, ИИ понял что ему конец, но сделать уже ничего не может.

Что за рассказ? А то интересно стало.
Это был небольшой рассказ, который я читал лет 20 назад. Теперь уже не найду наверно. Тогда многие экспериментировали с «киберпанком» в их понимании и было множество писателей, теперь плотно забытых.
DmitTrix мне сообщил, что это был рассказ Герберт В. Франке, «Последний программист». Вот прямая ссылка — www.e-reading.club/book.php?book=60658
UFO just landed and posted this here
Ну да, PHP язык весёлый… один тип массивов на все случаи жизни, с очень логичным поведением для развлечения программистов.
Я имел ввиду, что для большинства жизненных случаев достаточно упорядоченного массива и массива с доступом по ключу, а не только массива с доступом по ключу и прикольной логикой.
Задача программирования не в том что бы контролировать электричество, а в том что бы решать проблемы реального мира. «Реальность» это не то что происходить внутри компа, а то что происходит снаружи. Абстракция которая упрощает решение проблем — приближает программиста к реальности, а не отдаляет его от них.

Более того, идея что реально только электричество — это именно что отдаление от реальности, подмена реальности… абстракцией.

Страх же «отупеть» довольно странен. Все кто использует русский язык, но не является филологами — дураки которые не могут использовать русский язык?
UFO just landed and posted this here
UFO just landed and posted this here
Вообще-то уже сейчас программирование по большей часте задача гуманитарная. Или вы думаете много матана надо знать, чтобы клепать сайтики?
Ну вообще-то это не потеря контроля, а использование наработок, опыта и знаний нескольких поколений программистов для упрощения создания ПО. Вот какая мне разница, что там происходит в железе или какой машинный код исполняется, когда я написал цикл? Мне важно, что описанные мною действия будут правильно воспроизведены и я доверяю разработчикам .Net/MRI/gcc/и тд в этом. Ведь они тоже стараются использовать наработки, знания и опыт, чтобы получить лучший вариант кода и продукта.

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

Если же выбранный инструмент не позволяет эффективно решать задачу — стоит выбрать другой. Если не подходит «эй компьютер, сделай мне эту хреновину», то это делается чем-то другим. Важно, что низкоуровневые инструменты никуда не исчезнут и в большинстве случаев сделать что-то по своему будет возможно. Но наиболее вероятно, что кумулятивный опыт разработчиков будет намного больше, чем опыт одного программиста, которому нужен контроль, и необходимые вещи уже будут сделаны корректно и оптимально.
UFO just landed and posted this here
Понятно желание передавать мысли в чистом виде и не делать поправки на среду передачи данных, но так устроен язык, из множества вариантов в определенной группе людей родился самый эффективный метод коммуникации, который удовлетворял требованиям. Если у Испанцев не было никогда требования обвинить кого-то в случившемся и они позволяли вещам «просто случаться», то и такой абстракци не было заложено в язык. Представьте что было бы если не изобрели булеву алгебру и не было бы всех эти XOR, AND и т.д. Все равно нашли бы способ, как сказать машине что от нее нужно, придумав ту абстракцию, которая бы решила задачу. Ничего плохого в абстракциях не вижу, мы в своей голове достаточно высоко сидим с позиции абстракций, никак не контролируя сердцебиение и другие низкоуровневые процессы, что высвобождает нам кучу времени для размышлений, написания программ и т.д. По сути абстракции экономят самый ценный и невосполнимый ресурс- время.
Я не программист, но скромно постою в уголке вот с таким мнением. Мне кажется, что проблема отчасти обусловленна стремлением бизнесменов извлечь выгоду «сейчас» ценой проблем «потом». Ветеринары пичкают коров килограммами антибиотиков, получая устойчивые штаммы. Производители товаров заворачивают продукцию в десять слоев упаковки, от чего на суше растут горы пластикового «шлака» который природным утилизаторам совсем не знаком, программеры в спешке пишут костыли, и так далее.

Человек уже достиг огромных возможностей, но остался недальновидной суетливой обезьяной, озабоченной сиюминутными ценностями и статусом.
А мне все же нравится стиль программирования типа: «Джарвис, вот тебе чертежи в каталоге data/data/docs, изготовь в железе, покрась в оранжевый, прошей выхлоп на EURO3».
И пофигу (лично мне) какие там в процессе его работы типы переменных.
Тогда уж ещё лучше — «Джарвис, вот тебе эскиз, обязательные характеристики перечислены в файле рядом, остальное на твоё усмотрение. Бюджет производства экземпляра там же».
Фил, поздравляю с очередной ступенью просветления! Серьёзно.
И да, ложки не существует.
Концептуальный изъян твоего мнения, изложенного в этой статье, в том, что ты думаешь что понимаешь хоть что-то. Это заблуждение.
Ты не знаешь ничего ни о природе электричества, ни о том, благодаря чему вообще возможно существование этой природы. Электричество — это просто ещё один уровень абстракции вбитый в тебя в школе.
Русский язык сам по себе нейтрален. Окрашиваешь его так или эдак именно ты. Проблема в тебе, а не в языке. Ты просто не готов воспринимать и строить сложные конструкции. Даже свой идентификатор ты сократил до трёх букв.
Давно занимаюсь системами Reinforcement learning. И вот у меня возникла задача написать RL на языке ActionScript 2.0. Это который Флеш, да ещё и старой версии.
Как же я ругался. Никаких тебе векторных вычислений. Никаких Dataframe-ов. Всё писать через кучу вложенных циклов, которые на AC 2.0 работают не сильно быстро. В общем, я написал кучу своих функций для векторных вычислений, функцию для KNN-регрессии, функции вышли довольно глубокой вложенности, но в принципе задача была решена.
Это я к чему. Мне нравится, когда мы можем дёшево поднять уровень абстракции. Мне нравится, когда кусок программы можно не писать, а просто подключить в виде «чёрного ящика» — если этот ящик неплохо работает из коробки, и при этом пригоден для тонкой настройки.

Или ещё. Я как-то работал с нейросетями на Matlab. Там есть две нейросетевых библиотеки — старая и новая. В старой можно заглянуть в любой вес любого нейрона, его можно подправить вручную. В новой… Заглянуть можно сильно не во всё, и точно нельзя всё поправить вручную.
В первом случае передо мной был сложный чёрный ящик, в который можно влезть до уровня отдельных переменных — сложно, но можно. А во втором был просто сложный опечатанный чёрный ящик =)

Так что абстракции можно реализовать с сильно разной прозрачностью. И в таком случае они необязательно становятся проблемой
Вот поэтому-то, самый лучший язык тот, на котором ты уже пишешь много лет.
Статья очень, очень умная, аж зарегился чтоб комент написать.
Сам автор статьи в силу возраста еще не врубился в то, что уже нарыл.
1. Учили в вузе прогить в 82. 8разрядный аля копия какого то американца60х, создали у нас в 70х, тумба-комп (небольшой размер считался), клава (!), световой карандаш (кнч с проводом) для исправления на экране символов, блок из 8 тумблеров для карандаша, монитор символьный. Очепятался, выставляешь тумлерами 8раз код нужного символа, подносишь карандаш к символу на экране, жмешь типа ентер и обана, готово! Потом фортран на ЕС (шкафы) и дальше pl/1, басик. Кто был особо заточен, то самозацепил во вред пьянкам кобол, ассемблер. Бесконечные зависания отечественных ЭВМ (ну компом их тогда не называли), наладчики быстро меняли перегоревшие платы, зайдя за шкафы и открыв из зады, потом они у себя выпаивали сгоревшие элементы и впаивали новые на платах, заливали программатором микропроги в пзу. 88 г — польская Мазовия (экспишка с ЖД 10М и двумя флопами на 5 по 720К) открывает графический басик и остальные чудеса американского софтпрома с примером в виде принца. Мы по старинке начинаем в фортрана 77 под старые золтопесочнонесущие задачи и тут же уход в космический дибейс < — это важный момент. То, что ваяли за месяц на пл1, дибей — за 10 мин. с нуля. Даст ист фантастиш!!! Заказы на бюсгалтерские и прочие базоданные задачи как ливень из денег. Боги, а не прогеры в то время железных феликсов на столах приятных женщин.
2. Я знал одного суперчела электронщика-системного прогера, который читал как я здесь пишу, 16ичный машкод, а ассемблер, как русский лит+матерный+остальной, взял мсдос, продебажил и написал за месяц ос на Корвет в 92 году, дрова писал под любое устройство, если хоть какая инфа есть по эл.базе (ну из чего железо сварено). За ним вояки с далик самолет присылали. Мозги как дом советов, но системщик. На все остальные ЯП, кроме С, смотрел как на игрушки для взрослых. Неинтересно. Он генетик.
Что к 92 поняли: бизнес прогера — это не знания всей хрени из ЯП, а скорость, в которой дедлайн — НЕ последний остаток кислорода. А тогда нас было по пальцам пересчитать. А теперь конкуренция мама не горюй. Да, С и вижн (ассемблер уже тогда был только для системщиков) — приближали нас к железу, но заказчик требовал «вчера». Поэтому от дибейса прыгнули в фохпро, затем ко всему, что быстрее с заказчика бабло стряхивает без ущерба имиджу и привязывает его к кошельку прогера навсегда в качестве дойной коровки, так как мало кто из современной школоты возьмется проги тех лет доработать. Доятся и поныне. Выбор ЯП с дааааальним прицелом, как история показала.
3. Если (1), то много конкуренции, но больше возможностей забить на нищету.
, в противном — (2) будешь генетиком железа — то большие деньги, то их часто нет. Объединение (1) и (2) — утопия или как быть никому не нужным, прожить жизнь среди хрени и не остаться здоровым телом и психикой.
Поэтому выбирая ЯПы думать надо думать о следующем: быстро делаем деньги, привязываем заказчика на очень долго, есть перспектива развития ЯП.

Да, и вот еще что: вы что поколение Z думаете, будете всегда этой хренью заниматься до крышки? Это же самосожжение, а не икаровский полет! Это же удел мойщиков золота на эльдорадо. Двадцать лет и все. Дальше только аналитик, продажник, рукпроектами или просто хозяин с головной болью за свое детище в заднем месте. Это я о чем: ЯП — не самое в вашей профессии, а только вынужденные ступени к тому, чтобы с 45 лет жить безбедно в приятном месте нашей или выбранной страны, и делать только то, что не требует дедлайна — бича и палкой по пяткам всех прогеров, жить не ходя под себя до гораздо большего возраста, чем в мечтаниях правительства на поднятие пенсионного «не доживут».
UFO just landed and posted this here
Очень правильный вопрос для пишущего прогера, а не админа и озе братии, так как кодировка — это нередко захватывающая тема. Спрыгивают по нескольким причинам: 1) надоедает однообразие синего воротничка; 2) устают от переходов с ЯП1 на ЯП2; 3) здоровье; 4) желание значительно больше заработать и больше времени отдавать семье; 5) постоянные дедлайны и ответственность; 6) озе.
У меня было 4), потом резко 3). Статистика показывает, что дальше 45 очень мало, кто кодирует. Все уходят за еще большими деньгами или уже хватит и хочется заняться чем то другим, но не кодировкой, особенно по корявым постановкам, типа вот этой картинки
toster.ru/q/6866, которую я увидел в 88.
Нередко админами и сапортами продолжают. Но мое перлы — это исключительно по ЯП -первичное свойство натурального прогера.
UFO just landed and posted this here
1 — это 2,3 и более лет в одном крупном проекте свои грядки шлифуешь.
2 — весело в теории. Ставиться задача и сроки, а на новом ЯП всё идет как всегда и это не нравится шефу, заказчику и коллегам.
3 — надо задуматься, а почему так мягко говоря мало кодировщиков за 40.
4 — да, да, да. Когда занялся финансами порядок к з/п прибавился, а пахать и особенно думать требовалось на порядок меньше.
5 — читаем книжку «Дедлайн» Де Марко.
Жизнь оооооочень короткая. Продажником редко становятся вообще, кто бы то ни был, а уж тем более прогер. А вот рукпроектофиса в приличной корпорации получает не 100К, и не 200К, а 300К. Когда входишь в деньги, которых хватает на многое и еще остаются, то розовые очки — я пуре прогер и мне об колено все эти морочки с управлением — сваливаются, топчутся и остаются «там», где синий цвет за стеклом подержанного соляриса.
UFO just landed and posted this here
3 — надо задуматься, а почему так мягко говоря мало кодировщиков за 40.

Пока отрасль растёт (а она растёт всю дорогу с середины 20 века и останавливаться не собирается) — у вас всегда программистов «в годах» будет мало. И далеко не только потому, что они куда-то там на агромадные деньги уходят. А просто потому, что молодёжи в отрасли каждое поколение будет всё больше и больше.
все факторы приведенные выше будут играть положительную роль в омолаживании отрасли, особенно при повышении уровня ЯП.
Конечно. Вопрос только в том, какие из них существенные, а какие — на уровне «я художник, я так вижу». Так-то и вы лично в энтропию вклад вносите, но на фоне астрономических объектов вашим вкладом можно просто решительно пренебречь.
И еще: вам по своему повезло, что столько ЯПешек расплодилось и околояпешной хрени. Пройдет три десятка лет и кто будет поддерживать весь зоопарк софта на пхп, жабе, эрке и прочих буквах? Думаете, что вас много и все также будет с конкуренцией? Нет. Многие срулят с этого каната над пропастью дедлайнов, глюков и нового умасбродства разработчиков ЯП. Поэтому, выбирая ЯП надо заморачиваться не осознанием гмомодификации своих мозгов линейным, объектным и прочими «яйцами только в профиль», а тем, как через 30 лет доить истеричных от отсутствия старых профи заказчиков сегодняшнего софта. Типа, как хобби, тряхнуть стариной с пайтОном, когда все прогеры будут просто говорить ИИ: «хочу хрень для заказчика Пупкина, ТЗ завтра пришлет, а не пришлет, напомни ему, но осторожно».
Вы с пайтОном погорячились маленько :)
Тут перлового наследия в корпоративном сегменте вагон и маленькая тележка. Просто пока ещё эти издержки не вылезли на осязаемый уровень, так чтобы до высокого руководства корпораций это наконец таки дошло, что переходить на новые рельсы надо было уже очень давно. Надо писать автоматические переводчики для языков программирования. LLVM тут прям вовремя выстреливает. Диалектов уже очень много и средний уровень разработчика будет только падать, из-за возрастания количества накопленных знаний в IT-среде.
На счет гада это я к эдак году 2035 отнес вас нынешних «горячих финских парней», из колыбели конца 90-х. Реально, еще где то мэинфреймы тащат воз, перфокарты в подлодках США (они то не подвержены магнитному дестрою), виндовоз 3.1 на мсдосе 6 не меняют. А чё, работает, нахрен бабло тратить. В Калининграде стоит морской корабль космического наведения ракет «Космонавт Пацаев». Был на консервации. Там Минс32 в полной сохранности со всей периферией 70лохматого года. Хоть щас заводи на точки.
Но где взять спецов? Все уже забили, кости ломит, хвост отваливается. Тяжкий труд у прогера. Немчуры еще с 80х от компов отлынивают. Только азия (степбайстеп) заполоняет пространство. Иначе бы вы были на вес золото при таком темпе заполнения мира дискретным железом.
Блин, какие то п мне минусов наставили. я же не пришел тут кого то критиковать или в маинпрогеры лезть. сдалась мне эта печаль.
Автору огромный респект. Действительно, прогерство и ЯП наносят свой визит мышлению, делая не только из нас под стать авторам ЯП, но и влияя на менталитет. Раньше от нас шарахались (свитер, небритость и логические речевые структуры), а теперь тянуться. Слова «версия», «апгрейт», «баг» и прочий птичий сленг, который мы не выделяли, стал уже в бизнес среде чем то мажорнистым. Народ потянулся к ботаникам.
Больше как бы напрягает тот печальный факт, что низкоуровневая разработка все еще имеет место быть. И получается дикая пропасть, между теми кто таки проэктирует теже процессоры, и теми кто их потом использует. И она растет.
Прямой путь к жрецам от технологий, с тайными знаниями, обрядами, вот этим вот всем )
Или к переходу всего низкоуровневого на ИИ, с полной не возможностью фикса давно сделанных багов, бо никого живого, кто сможет глянуть что не так — просто не будет…
Ваш вопрос очень правильный. Он приходит со временем.
Надоедает прикладуха. Кто то воще забивает на писанину, берется за орк, сертифицируется и живет сисадминкой в штатах. И таких я знал.
Но мысль углубляться к корням — она правильная. Хуже не будет, если только в азарте на завалить основную работу. Сразу ведь не перепрыгнешь в системщики.
У меня был выбор когда проходили ТАУ, паяли, че то прогить пытались на ассемблере. Препод был г«но в том институте. В другом другой уже опоздал, я засел за фортран всерьез и мне уже платили. Мне понравилось много и сразу. Есть сварщики 6 разряда, а есть операторы сварочных станков с ЧПУ. И те и другие — нужны, а что им прет, то сами на ромашке своей души делают выбор.
В любом случае, если душа запела дрова попилить к управлению освещением в квартире или какого робота родить, надо обязательно попытаться.

Тут перлового наследия в корпоративном сегменте вагон и маленькая тележка.


До руководства достреливает, что «новые рельсы» это Oracle, который внезапно стал нежелательным явлением. Или какая-то модная технология, которая точно так же внезапно будет объявлена устаревшей.
орк пока очень сильно рулит корпоративным сегментов в мире. ларри бдит и сразу скупает проявившихся серьезно конкурентов и убивает в своих застенках.
вы еще увидите зе енд жабы.
возможно монополия реляшки и сиквеловские запросы уже морально давят как старье. вероятно как в истории ксероксных шрифтов придерживают что то архиважное, выживают из старого как из нефти автомобилестроение. в айти будут до последнего один и тот же код 100 млн раз продавать. отличный бизнес.
на счет переводчиков было дело уже в 80-х при переходе на персоналки. оказалось проще и гораздо лучше задача выглядит в новой итерации кода на современном языке. никто не любит чужой код на чужом языке, а уже перевести его на ЯП2 младше на 20 годин ЯП1, заставить работать и восхитится божественностью ума того автора — ну редчайший случай. Вывод: проще пойти в булонский лес и трюфель найти.
Автор, а за какими уровнями абстракции ты при употреблении пищи? Думаю пора бить тревогу, что мы не знаем в принципе откуда берутся те или иные продукты. А то приходишь такой в столовую, говоришь: «мне котлету», опа, и котлета почти магически появляется у тебя в тарелке. Это неправильно. Надо идти и выращивать дикого кабанчика…
Правильная мысль. Жоем не знамо что в булочке из гмошной пшеницы (а пшеница ли это?).
— Еда есть? — Каша.… Пластиковая (1986 г, х/ф Кин-дза-да).
Но работать в постоянке асматиком & шарпером & слоном с либками — прощай жизнь. А изредка — ну это не айспрофи. Специализация была изначально — или системщик-канифольщик, или прикладник-шахматист. макдональдс — 12 челов как лента конвейера ради быстробутера. К коротким спринтам клиенты тянуться. Клиенты — это ради кого или их бабла пишутся проги. Приличной герле рафаэли без, хотя бы, сонаты не нужны. ЯП должен косвенно давать заказы наперед и короткий ЖЦ.
Самое время вспомнить сакраментальное: «Любую архитектурную проблему можно решить путём добавления ещё одного уровня абстракции. Любую, кроме проблемы слишком большого количества уровней абстракции...»
Выглядит как демагогия. Потому что не описано а что же за проблема со слишком большим количеством абстракций. Если сложно работать или просто запомнить, то можно закрыть несколько абстракций новой но одной. И работать уже с ней. Само по себе количество в вакууме — не является проблемой.
Проблема всегда одна и та же: сложность. И убрать её из системы принципиально невозможно. Её можно только перераспределить (попутно увеличив).
Конечно, общая сложность системы никуда не денется. Но я не знаю ни одной реальной задачи когда нужно сложную систему охватить целиком за один раз. Всегда можно разбить на более мелкие задачи на разных уровнях абстракций и сделать по отдельности. Если у вас есть проблема с количеством абстракций, то объединение нескольких в одну (то есть фактически добавление новой абстракции) как раз таки и решит эту проблему. Я допускаю что это может быть не всегда так, но в общем случае ваше изначальное утверждение неверно.
Демагогией же это выглядит как раз таки из-за обобщения которое рассыпается если задуматься. Я не пытался сказать что вы это специально, скорее пытался показать недостаток вашего утверждения.
Вы слишком серьёзны :)
К тому же это не моя фраза (именно поэтому она взята в кавычки), а вполне расхожий афоризм. Который, как любой афоризм, является «шуткой, в которой есть доля шутки».
Так я лично против вас ничего и не имею, мне не нравится сама фраза. В первую очередь потому что на мой взгляд она только выглядит красиво, но, как обычно в таких случаях и бывает, неверна.
UFO just landed and posted this here
В любом случае это можно лечить добавлением абстракций и разбитием этого монолита. Это не самый выгодный подход (как минимум не всегда), но это точно рабочий подход. А суть моего комментария была именно в существовании такого варианта, ни в коем случае не в его оптимальности.
Я допускаю что это может быть не всегда так, но в общем случае ваше изначальное утверждение неверно.
Вы будете правы только в одном единственном случае — когда вычислительная мощность и память — бесконечны. В остальных вариантах вы проиграете в производительности и памяти, так как их конечное число.
Абстракции — это отлично. Они могут превращать степенную трудоемкость множества задач в линейную. Вместо того чтобы писать X1, X2, X3… для каждого из Y1, Y2, Y3… (и не дай Бог есть еще и слой Z) можно единожды написать каждый, соединив их через интерфейсы более высоких абстракций. Причем каждым компонентом может заниматься профильный специалист, и делать это намного лучше чем мастер на все руки, работающий со всеми уровнями абстракций сразу. Разделение труда не зря было придумано.

А «сделай-ка мне вот эту хреновину» никогда не наступит. Потому что без внятного ТЗ — результат ХЗ, и без телепатии никакой ИИ этого не исправит. А подбробная спецификация того что человек хочет от компьютера это как бы и есть код.
Оно и с телепатией не получится. Потому что если человек не может сформулировать чего он хочет, то оно и в голове у него в виде каши находится.
Имелась в виду телепатия более глубокого уровня, читающая из мозга всю нужную инфу.
Так я об этом и говорю — там просто нет нужной инфы, ее все равно придется достраивать.
Да запросто!
Сейчас УЖЕ этим занимаются.
Контекстная реклама, машинное обучение и прочие классные вещи, если их вывести на новый уровень, вполне способны будут предсказать что ты хочешь от системы даже если ты это сформулируешь как «сделай-ка мне вот эту хреновину».

Простой пример: ты забивал гвозди и сломался «хитроназванный» молоток. Ты посылаешь запрос: Купи-ка (сделай-ка) мне такую хреновину… А машина тебе такая — ОП! Молоток! )
Или читал ты книгу по методологии создания молотков при помощи хитрой штуки и захотел сам попробовать. Ты пишешь запрос: Сделай мне такую хреновину… А машина (посмотрев что ты читал и сравнив с тем, что обычно после этого заказывают и что упоминается в прочтённом" тебе такая — ОП! Хитрая штука! )
А подбробная спецификация того что человек хочет от компьютера это как бы и есть код.
А уровень подробности спецификации и есть абстракция. И смысл абстракции как раз приводит к тому, что бы для решения задач можно было отбросить как можно больше деталей и сосредоточиться на главном, а детали переложить на машину.
UFO just landed and posted this here
Вот хороший пример: ты хочешь молоток с загогулиной (например сапожный), а ИИ выдаёт тот, что Гугл считает сапожным (а ИИ именно так и работает), и так как ты имел ввиду что-то немного другое, ИИ начинает тебе объяснять что ты не прав (а с рекламой получается в точности это). Так как ИИ имеет неограниченный запас энергии и аргументов (попробуйте поговорить с какой-нибудь Алисой), он рано или поздно сломает тебя и ты примешь то что он сделал. Несмотря на то, что нужно было нечто другое.
Я прокомментирую вчерашним кейсом из реальной жизни embedded программиста.

Есть аппаратный протокол подключения внешней аппаратуры к процессору — SPI. Он простой как три копейки, и в процессорах реализован аппаратно.
Есть моя функция, которая общается с SPI через библиотеку от изготовителя. Есть примеры использования этой библиотеки. Смотрю в пример, пишу аналогично — и получаю странности в процессе. Чаще всего работает хорошо, но иногда — внешняя аппаратура (в моем случае — LCD) начинает вытворять чудеса, явно получая неправильные команды.
Нормальный программист первым делом ищет ошибки у себя в коде. Не нашлись. Написал тестовую программную реализацию SPI на уровне размахивания физическими ножками — работает (уже хорошо — LCD исправен и плата корректная), но так оставлять в релизе нельзя (как минимум надо скорость на порядок больше). Начинаем спускаться по уровням абстракции, благо библиотека с исходниками. Раз функция, два, три, четыре, дальше обращение в порты процессора. Вроде все выглядит логично (правда количество #ifdef на все случаи жизни зашкаливает). Подключаю осциллограф (потребовалось 4 канала), и вижу, что я передаю один байт, а на выходе почему то передается 11 (!) бит clock, то есть некратное байту количество бит, да еще прерывание о завершении операции выдается заранее, чего быть не должно.
К этому моменту появляется ощущение, что виноват следующий уровень абстракции — аппаратная реализация SPI внутри процессора. Смотрим hardware errata, и о чудо!

nRF52832 Rev 2 Errata v1.1
3.9 [58] SPIM: An additional byte is clocked out when RXD.MAXCNT = 1
This anomaly applies to IC Rev. Rev 2, build codes QFAA-E00, CIAA-E00, QFAB-E00. It was inherited from the previous IC revision Rev 1.
Symptoms: SPIM clocks out additional byte.
Conditions: RXD.MAXCNT = 1; TXD.MAXCNT <= 1.
Consequences: Additional byte is redundant.

Workaround не описан, но ключевое слово SPIM подсказывает, что проблема в передаче по DMA. Выключаем DMA (благо он для этого изделия не обязателен), SPI начинает работать корректно.

То есть для понимания и исправления проблемы мне потребовалось спуститься от уровня функции на Си до аппаратуры процессора.
Лично я не вижу в абстрагировании ничего плохого и сейчас объясню почему.

Программист, как сказано в статье, на данный момент является интерпретатором (прослойкой, если хотите) между бизнесом и машиной. В бОльшем количестве ситуаций, работа сводится к решению определенной бизнес проблемы. Да, большую часть проблем (если не все пожалуй) можно решить низкоуровневыми языками. Но если вам нужно перевезти тонну песка из пункта А в пункт Б, сомнительно что вы будете использовать телегу с конём (условно), а не самосвал.
Тоже самое и тут: зачем писать 1000 строчек кода, если определенный язык, может решить эту задачу за 10 строк?

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

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

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

Из недавнего на эту тему — сказали добавить столбик в репорте — добавили. А то, что теперь в репорте два одинаковых столбца — ну наверное так было надо. Ну как так-то?..
UFO just landed and posted this here
Менеджер, который думает над дев задачами… За последние 10-ть лет — это было худшее что я встречал )
Менеджер, должен делать так, что б было удобно работать.
Выбивать бюджет не то чего не хватает, координировать отпуска что б не вышло что все ушли перед релизом, пинать всяких не сознательных граждан на предмет всяческих аппрувов, пинать бызнес чтоб они не звонили лично девелоперам с одной стороны, и быстрее рожали требования с другой, решать проблемы кадров, красиво показывать вышеозначенному бизнесу что все идет по плану (или не совсем все, и прояснять что именно мы куда перепланируем), и все такое.
Для остальных задач нужен ну совсем не менеджмент. И этот не менеджмент нужен с функцией интеллектуальной обработки поступающей инфы, а не просто «пересылки емейлов» в гитхаб.
UFO just landed and posted this here
банальное добавить столбик в репорте — это 50% ентерпрайза.
в процессе:
  • надо чуток изменить запросы к базе (не забыть и не сломать имеющие место быть оптимизации перформанса)
  • обновить скрипт на ksh который этот запрос должен вызвать
  • обновить мапперы которые должны будут понять что к ним пришло и зачем оно им надо
  • обновитиь юай и обеспечить его корректный вид
  • обновить настройки сервиса генерирующего собственно файл с репортом
  • проверить что те, к кому этот репорт должен прийти, в курсе что он поменяется
  • .....

И вы таки не поверите, но это все — дев задачи. Требующее анализа, планирования, и девелопмента. И отмазки «а я не знал, что этот репорт на самом деле часть более другого репорта, который в результате при генерации уронил прод, бо это не мое дело думать о том что я делаю» — они как бы не очень катят…
Совершенно верно, то что вы перечислили — это дев-задачи (кроме, возможно, последнего пункта). А вот «подумать, нужен ли вообще столбик в репорте» и «проверить, нет ли рядом такого же» — ни разу не дев-задачи.
Простите, а цитату про «подумать нужен ли столбик» — вы ее у кого взяли? У меня было только про их, столбов, именования )
А девелопер, которого не волнует как его код будут юзать… Ну, это, скажем так, не идеальный вариант. Но, весьма подходящий под индусскую идеологию — «сбилдилось, все остальное не мои проблемы, не сбилдилось — проблемы с билдом (тоже не мои)».
Мне кажется, Вы взяли факты, опыт и сделали прямо противоположный логике вывод: проблема не в абстракциях, а в слишком большом количестве различающихся реализаций! Язык (и обычный и программный) в идеале должен быть один, но максимально абстрагированный от реализации, потому, в что в жизни нам важен результат, а не подкапотные механизмы :)
Именно в разделении труда состоит сила человечества (привет, Адам Смит)!
Мы все существуем в рынке, и рассуждать нужно рыночными терминами.
Главный стимул появления новых ЯПов это увеличение скорости разработки. Стоимость ПО складывается главным образом из недешёвого рабочего времени разработчика.
Меньше времени потратили на разработку, значит получили конкурентное преимущество.

Великолепная лекция Боба Мартина на тему эволюции разработки ПО (от Тьюринга до Java и Agile):


Я думаю, что вы слишком смело обобщаете:
Мы все существуем в рынке, и рассуждать нужно рыночными терминами.
Рынок только там где существует обмен. В мире же есть так же места где раздают бесплатно.
Я не вижу ничего плохого в абстракция и уходах на уровни выше. Задача программиста, всё же, логику реализовать, а не перекладывание по регистрам как самоцель.
Проблема в другом.
Первое.Не существует культуры решения проблем, если эти проблемы возникают уровнями ниже. Если есть проблема безопасности или просто баги, то это просто может приводить к обружению всего, что человек надстроил выше. И если с багами в части функциональности и работоспособности ещё как-то мирятся, то с багами в безопасности забивают до тех пор, пока где-то не прорвёт.
Второе. Оверхэд. Дикий оверхэд. Когда привыкли просто палить из пушки по воробьям, причём из многоствольной пушки, потому что автор пушки решил, что вместо трёх пушек для разных областей лучше сделать одну. И не удобную, а просто со спаянными тремя стволами вместе. Вдруг когда-то кому-то понадобится использовать сразу две. В итоге имеем громоздкое нечто. Хороший пример — современный веб. Местами крутой, но совершенно прожорливый на ровном месте.
Программистами станут лощеные гуманитарии

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

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

Но кто-то считает, что это произойдёт быстрее (Slack из 50 строк кода, поисковик из 75 строк, фейсбук из 150 строк — как Вам такое?).
Slack из 50 строк кода, поисковик из 75 строк, фейсбук из 150 строк — как Вам такое?

Можно посмотреть?
Да нефиг) Какое-нибудь автоматизированное развертывание вордпресса и подобных проектов
Если бы человечество следовало вашей логике о ненужности высокоуровневых языковых конструкций, мы бы сейчас все еще на стенах в пещерах рисовали а не на хабре сидели.
Проблема в не языках программирования и уровнях абстракций. Главная проблема каждого человека заключается в способности осознавать свои собственные желания и умении четко формулировать их окружающим людям.

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

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

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

Скорее в не способности )
Но, именно эту проблему, теоретически, решают всяческие психологи, коучи, корректоры и прочие красивые слова. А вот как они ее решают — это уже другая печальная история…
Лет 20 назад я понял, что любой компьютер занят только одним — обработкой данных. Любой ЯП — средство для обработки данных. Не нужно вообще думать о языках, нужно думать о данных.
30 лет назад я понял, что ЯП, СУБД и прочая хрень — это отличный источник растущего дохода, если с помощью них быстро можно выразить мысль заказчика. А это: короткий код/процесс кодирования, шустрая БД и (!!!) умение быстро разобраться в ТЗ «качелей» заказчика и грамотно раскидать работу между коллегами. ЯП выбирался один для всех за исключение системных вещей и на длительный срок.
Все оказалось элементарно просто.
И сейчас так. Ничего не меняется. Раньше кларионщики, сегодня, к примеру, пхпшники.
Уже в конце 80х с приходом персиков работали так, как сейчас называют эджайл — на коленях у заказчика. До нас, со второй половины 70х — то, что назвали потом скрамом. 1 во 1. Меня учили этой организации разработки: еженедельные и экспресс-собрания, плакаты-доклады (!), гантирование и др.нормальная для большого проекта обсуждаловка-распределялка-итогосчиталка.

Фам Нювен несколько лет провел, обучаясь программировать и исследовать.
Программирование восходило к началу времен. Как та навозная куча за замком
отца. Когда ее промыло ручьем на десять метров вглубь, обнаружились
искореженные корпуса машин — летающих машин, как говорили крестьяне, еще от
тех великих дней колонизации Канберры. Но та навозная куча была чистой и
свежей по сравнению с тем, что лежало в локальной сети "Репризы". Были
программы, написанные пять тысяч лет назад, когда человечество еще не
покинуло Землю. И самое чудесное (самое ужасное, как говорила Сура) было то,
что, в отличие от бесполезных обломков прошлого Канберры, эти программы все
еще работали! И через миллион миллионов запутанных нитей наследования многие
из старейших программ все еще выполнялись во внутренностях системы Кенг Хо.
Например, методы слежения за временем у торговцев. Поправки вносились
неимоверно сложно — но на самом дне лежала крошечная программа, которая
гоняла счетчик. Секунду за секундой отсчитывала система Кенг Хо с того
момента, как нога человека ступила на Луну Старой Земли. Но если
приглядеться еще пристальнее… начальный момент был миллионов на сотню
секунд позже; момент "ноль" одной из первых компьютерных операционных систем
Человечества.
Значит, под всеми интерфейсами верхнего уровня лежат уровни поддержки,
слой на слое. Какая-то часть этих программ была создана для совершенно иных
ситуаций. То и дело несоответствие рождало фатальные инциденты. Вопреки всей
романтике космических полетов, чаще всего катастрофы вызывались древними
забытыми программами, которым удавалось взять реванш.


Вернор Виндж. «Глубина в небе»

Интересная тема со второй половины скамейки пошла в депрессивном направлении. Много дряни НЕпрогерской глазоушами жуют, потом здесь хороу устраивают — апокалипсисы, нло и розетка без вилки (самое ужасное).
ЯП — это язык программирования (для тех кто снизу читает коменты).

Подскажете ли, какой шрифт и IDE используются в вставках этого поста?


image
image
Тут мы имеем дело с VSCode, цветовые схемы из расширения daylerees.rainglow, шрифт — firaCode.

Спасибо за ответ, не уж то шрифт и цветовая схема понравились :)

Может вам просто квалификацию поменять, стать каким-нибудь kernel программистом, или например, в геймдев податься. Там все куда ближе к железу.
Нечего удивляться, что когда решаешь бизнес задачи нa платфгормах для решения бизнес задач — то уклон будет в бизнес логику, а не в то что под капотом.
Меня в этом плане особенно пугает Web и настольные приложения, построенные поверх него (aka Electron). Количество слове абстракции зашкаливает. Например, Typescript -> JavaScript -> HTML -> браузер -> нативный код.
Лихо вы нарисовали JS над HTML.
Это на самом деле совсем не так.

Тайпскрипт улетает еще до рантайма.

Остаётся всё то же, что и во всех других браузерах, только упакованное одним локальным куском. Ничего особо страшного.
JS же компиляется при загрузке страницы. т.е. должено оставаться нативный код в браузере
UFO just landed and posted this here
Во что? Это интерпретируемый язык с опциональным JIT.

Угу, где JIT значит Just-in-time compilation.

UFO just landed and posted this here

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

Есть у меня один знакомый, который все время доказывает, что все, кроме ассемблера — полный отстой, и что весь софт должен писаться только на ассемблере… Сам он работает в несколько другой области, сисадминит помаленьку…
Как-то попалась маленькая задачка на ruSO -надо было биты поковырять. Попросил его написать на ассемблере. Результат был забавный — во-первых, он написал раза с шестого, все время что-то не так шло. Во-вторых его код оказался раза в полтора медленнее, чем тот же алгоритм, скомпилированный с С. В-третьих, решение на ruSO на C обставило оба эти решения раза в 3-4.

Так ли уж это плохо — отдавать взаимодействие с железом — железу? Которое справится с этим лучше? Почему обязательно уход от непосредственной работы с железом должен вести к "какое все громоздкое, неправильное и неповоротливое"?
Некоторые мнят из себя асматиков, но настоящие, хотя бы «3 сорт — то же не брак», редкость.
Они кучкуются в странах, где производство с применением микропроцессоров развито и по дефолту в США. У нас в ВПК, производственных корпорациях, инфобезики. Редкая специализация, требующая значительных знаний в области электроники.
Неновые языки тоже иногда задают очень непростую связь с peaльнocтью. Например, на языке APL согласно википедии всего в одну строчку можно напиcать игpу Жизнь Kонвeя — life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} — нечто.
Язык TeX, будучи универсальным, порождает весьма интересные кoды даже для самых простых задач, например, расчета чисел Фибоначчи.
ООП, фреймворки, визуальное программирование, программирование близких к человеческим языках и пр. многоуровневые абстракции убили саму суть программирования. Если раньше программировали на С/С++, Паскале и пр. ЯП, при этом стараясь оптимизировать программный код (часто — с использованием ассемблерных вставок), то сейчас, используя библиотеки готовых объектов (классов), накидав формы и объекты в визуальной среде программирования, легко и быстро написать программу любой сложности. И если раньше программный код даже растягивали по строкам при оплате по количеству строк программы, то сейчас программы могут иметь миллионы и десятки миллионов строк кода: МС Виндовс 7 скомпилирован из примерно 40млн строк кода (Вин3.1 — 2,5млн), МС Офис 2013 — 45млн строк, Линукс 3.10 — 13млн, Андроид — 12млн, Файрфокс — 18млн, Гугл Хром — 7млн, новый Фотошоп — 10млн (Фотошоп 1.0 — всего 128тыс.!); а управляющее ПО самых современных автомобилей может иметь и 100млн кода (т.е. производители просто накидывают готовые программные блоки, не делая никакой оптимизации кода). Любая универсализация и унификация программирования (с целью его упрощения) в виде ООП, фреймворков, визуального программирования, а также программирования на языках, близких к человеческому (к этому все и идет), и пр. многоуровневых абстракций, подразумевает огромную избыточность кода. Большие объемы устаревшего и неиспользуемого кода накапливаются в любых крупных проектах (как проприетарных, так и опенсорсных) с выходом все новых версий, негативно влияя на производительность и отзывчивость программ; и периодически программисты проводят чистку этого кода и АПИ (рефакторинг) и оптимизацию программ, ускоряя работу приложений, что потом ставят в достоинства вышедшей новой версии ПО. Те же Демки со сверхсложными алгоритмами генерации изображений и звука занимают всего 1024, 256, 128 и даже 64 байт (по условиям конкурсных программ).
То же самое с версткой сайтов и веб-программированием. Изначально все сайты выглядели минималистично и просто (наподобие еще более старого Гофер), а сейчас даже минималистичная версия сайта Яндекса (ya.ru) — это почти 50КБ кода; при том что печатная страница простого текста (если ввести без стилевого оформления в Блокноте) — примерно 2КБ).
В голливудских фильмах, кстати, можно наблюдать самые сверхвысокие уровни абстракции в программировании и работе с компьютерами ;) Например, хакеры для получения нелегального доступа к БД просто пишут команды типа «Взломать сервер ЦРУ»; или же, к примеру, для взлома шифра пользуются каким-то сверхсложным графическим интерфейсом (на экране какие-то сложные меняющиеся узоры с пиктограммами, по кот. быстро водят пальцем).
Кстати, кто знаком с mechanical sympathy — подходом и где про него можно почитать подетальнее?

Это как раз подход, учитывающий железо dzone.com/articles/mechanical-sympathy
И хорошо что убивают. Это овобождает железо от бремени соблюдения ожиданий со стороны языков высокого уровня. Мы так Итаник потеряли из-за чрезмерной связи с реальностью.
Итаник мы потеряли в силу его бессмысленности: компиляторы языков программирования должны были совершить чудо и найти по 6/9/12 и так далее команд на каждый такт исполнения. Чего, в общем, не понятно как добиться даже теоретически.
И в свою очередь, компиляторы не смогли, поскольку не были готовы.
Если упрощать, то популярность С притормозила развитие компиляторов настолько, что они не смогли.
UFO just landed and posted this here
ощущение что писал технарь истосковавшийся по гуманитарным наукам, пост можно свести к одному предложению «я не разбираюсь как детально устроены абстракции на которых пишу и боюсь что их за меня сделали хуже чем надо», а не вот это вот всё гендерно-гибкие языки, электричество в железяках, биты бытия
я не разбираюсь как детально устроены абстракции на которых пишу и боюсь что их за меня сделали хуже чем надо

Возможно так и есть. Но если эти абстракции лично мне кажутся излишними и перегруженными — где гарантия, что я не прав? ;) Взять, хотя-бы типовые конфигурации 1С! ))))

Как говорится: Если вы параноик, то это еще не значит, что за вами не следят!
Это вопрос скорее философский, чем программистский. И заключается он в том каким образом любой язык формирует стиль мышления.
И на него можно ответить одним словом — ПЛОХО.
Любой язык рано или поздно превращается в набор паттернов, а его носителя в зомби.
С ЯП все еще хуже — двоичная логика, сама по себе, бред напичканный логическими парадоксами, а уж носители и вовсе становятся придатками к компьютеру.
бытие и сознание, сознание и бытие. Язык — инструмент, само собой он задает паттерны поведения, но он же и дарит много возможностей. Контроллировать или поддаться — выбор каждого. Можно чахнуть над одним языком, всю жизнь — и суть не важно, низкоуровней он или наоборот.
Я как то взял простую задачу «создать массив, заполнить случайными величинами и отсортировать» и составил программу на всех языках, которые смог найти.
Результат то один и тот же, а разница только в том, сколько текста приходится набирать.
Но тем не менее, моя любовь — это С++.
Ресурс для решения разных тестовых примеров на разных языках :)
rosettacode.org/wiki/Rosetta_Code
Некоторые решения, на некоторых языках очень лаконичны.

P.S. Моя любовь, тем не менее, Forth (Форт) расширяемые и конкатенативные языки.
UFO just landed and posted this here
Например, парадокс Зенона, парадокс Лжеца, парадокс Брадобрея, буриданов осел.
И так далее и тому подобное.
UFO just landed and posted this here
«Парадокс в логике — это противоречие, имеющее статус логически корректного вывода и, вместе с тем, представляющее собой рассуждение, приводящее к взаимно исключающим заключениям. Логическая ошибка парадокса объясняется неверным выбором логических посылок, например, когда речь идет о предметах, не имеющих четкого определения (См. стрела Зенона).

Различаются такие разновидности логических парадоксов, как апория и антиномия.

Апория характеризуется наличием аргумента, противоречащего очевидному, общепринятому мнению, здравому смыслу. Антиномия — наличием двух противоречащих друг другу, якобы одинаково доказуемых суждений. „
(википедия)
===========
UFO just landed and posted this here
А математическая логика и есть двоичная логика — 0 и 1. И все логические парадоксы у нее остаются. Просто системы стали достаточно умные и предотвращают обвалы при возникновении логических парадоксов.
Бесконечный цикл один из таких парадоксов.
UFO just landed and posted this here
Начнем с того, что что двоичная система пока, что единственная поддерживаемая железом. Уже давно прогнозируется лазерные компьютеры способные иметь 7 и более состояний — и логика будет соответствующая.
Теоретически многомерные логики разработаны давно.
================
Собственно «исключительные ситуации» это и есть логические парадоксы.
=============
Когда бесконечный цикл возникает самопроизвольно то это и есть логический парадокс.
В виндовс он проявляется в виде «синего экрана смерти».
Какие, нафик, лазерные компьютеры! ))

Если вы за фотонные, так они для обработки тех же двоичных данных.

Вы как бы не совсем верно понимаете тему. Количество состояний системы может быть любым! хотите четыре состояния — просто добавьте бит. ;)

Двоичная выбрана просто потому, что МЕНЬШЕ уже нельзя.
Нет, не фотонные. Имеются в виду компьютеры, у которых та же память может иметь не два состояния, а больше.
Это вы «как бы не понимаете» — бит это либо 0 либо 1.
А когда — «красный», «оранжевый», «желтый» и так далее.
А двоичная выбрана не потому, что «меньше уже нельзя», а потому, то мы В ДАННЫЙ момент можем различить только два состояния — ВКЛ- ВЫКЛ.
у которых та же память может иметь не два состояния, а больше.

Память может иметь сколь угодно много состояний. Квант памяти, он же бит — два, да.
А когда — «красный», «оранжевый», «желтый» и так далее.

Ваши 7 цветов кодируются тремя битами и на этом можно построить какую угодно логику — хоть по принципу «камень-ножницы-бумага».
А двоичная выбрана не потому, что «меньше уже нельзя», а потому, то мы В ДАННЫЙ момент можем различить только два состояния — ВКЛ- ВЫКЛ.

Да все мы можем! Электротехника начиналась с вполне себе аналоговых компонентов, где не только могло быть выделено несколько уровней сигналов, но и вполне реализовались основные операции с ними (сравнение/сложение/вычитание/умножение и тп.). Мало того — во многих случаях это давало почти абсолютную точность и первые дискретные схемы не могли тягаться с аналоговыми в этом отношении.

Но время расставило все по своим местам… Простое пороговое сравнение ДА/НЕТ в сочетании с практически неограниченным масштабированием гораздо практичнее всех остальных самых экзотических вариантов.
Блин! Именно квант памяти может иметь более двух состояний.
Мне сложно что-либо объяснять тем кто не знает, что такое Логика, но попробую.
Какая разница между цветной картинкой и серой?
Ученые утверждают, что цветная БОЛЕЕ ИНФОРМАТИВНА.
Что информативнее — одно число от 0 до 7 или три бита?
Что занимает больше места в памяти 1 бит или 3 бита?
У нас были 8 разрядные процессоры, а теперь если не ошибаюсь уже 128 — а зачем7
Судя по контексту, я должен попросить Вас дать принятое в Ваших рассуждениях определение бита, иначе первый вопрос оказывается не связанным с обсуждением. И да, ответа на мой собственный вопрос я, видимо, не дождусь.
Как-то не по понятием получается: предъявлять другим и не следовать самому… ;) Это я про логику, которой вы, как я понимаю, по собственному мнению владеете в совершенстве.

1. бит — единица измерения информации в двоичной системе счисления.
2. Что занимает больше места в памяти 1 бит или 3 бита? — очевидно три. Но, только при условии, что под битом вы понимаете квант двоичного счисления, а не что-то еще.
3. Если же вы все-таки имели ввиду сравнение ячейки памяти на 8 (0-7) состояний и три двоичных, то вопрос с подвохом: что такое «больше места»? Места где? На листочке бумажки, или на экране? ;) Типа одна циферка или три? )) Количество информации, хранимое в этих ячейках, т.е. информационная емкость — одинакова.
Видите ли, современный способ хранения информации подразумевает хранение в ячейке памяти определенного электрического заряда — при одном значении это 0, при другом -1. Это НАША интерпретация содержимого ячейки памяти.
Пошли дальше, если одна ячейка памяти способна иметь 8 различных РАЗЛИЧИМЫХ состояния, то это приведет не к геометрической прогрессии, а к эспоненциальной — простая комбинаторика.
Ага… С математикой, значит, тоже так себе…

Одна 8-миричная ячейка эквивалентна трем двоичным. Всегда. Т.е. две восьмиричных, это 6 двоичных, 3, это 9 и тп… Т.е. тут (х3) — обычная линейная, даже не геометрическая.

Напоминаю, что есть что:
image

Красная — линейная,
синяя — геометрическая,
зеленая — экспоненциальная.
Ну это уже запредельная безграмотность.
Мы не используем одну ячейку как объект программирования.
unsigned short int smallNumber = 255;
unsigned int largerNumber = 70000;
unsigned long possiblyLargerThanlnt = 70000;
unsigned long long largerThanlnt = 70000000000;

А теперь посчитайте количество комбинаций при двух значения и при восьми.
То есть вы вообще не только логику не знаете, вы вообще ничего не знаете.
То есть, Вы утверждаете, что полезнее будет считать одну переменную состоящей из N восьмеричных цифр, чем из 3*N бит?
Вы вообще понимаете о чем идет речь?
Один байт при двоичной системе информации может содержать 256 различных комбинаций.
А при восмеричной будет -16 777 216.
Что опять непонятно?
В таком случае, что такое, по определению, один байт?
Вы же находитесь на сайте программистов и задаете такие вопросы — я балдю, Клава.
Один бит — это одна ячейка памяти, которая может находится в одном из двух состояний 0 или 1.
Один байт — это 8 ячеек памяти.
Вот только на самом деле байт — это, в широком смысле, наименьший адресуемый элемент памяти. Он может быть, в зависимости от процессора, любого размера.

В узком смысла байтом называется 8 бит. Бит, а не ячеек памяти!
Бурные аплодисменты переходящие в презрение.
Адресуемый элемент памяти — это массив, переменная, константа и так далее.
Слово «наименьший» Вы не заметили или исключили как не соответствующее Вашей трактовке понятия? И да, Вам и дальше будут задавать «дурацкие» вопросы, пока не будут уверены, что мы с Вами понимаем одни и те же термины одним и тем же образом. Ну, или пока не плюнут и не спишут Вас как не желающего доводить обсуждение до ума.
На самом деле? А вот наименьшим у нас, во всяком случае в С++17, является «short».
Но опять же это ТИП.
Тип переменной, константы, символьной константы.
То есть, наименьший адресуемый элемент памяти зависит от языка программирования? Ну, исключим интерпретируемые, в компилируемых языках — зависит или нет? Верно ли, что в бинарном файле, скомпилированном из C++17, адреса любых двух используемых элементов памяти различаются не менее чем на sizeof(short)?
Да. Мы можем использовать и битовые операции, но они выполняются путем сдвига от адреса.
Значит ли это, что некоторые бинарные файлы, в которые компилируется, например, Rust (в котором есть тип u8 и, соответственно, адресация с точностью до байта) невозможно получить ни из какого кода на C++17?
UFO just landed and posted this here
Ну, допустим, мы сейчас говорим о некоторой фиксированной архитектуре, где Растовый u8 имеет размер 8 бит. По утверждению собеседника получается, что в C++17 такая адресация, которую делает Rust, на той же самой архитектуре была бы невозможна.
Не знаю, никогда не сталкивался с такой необходимостью.
Зато столкнулся с фактом отказа читать файлы *.obJ созданные в блендере.
В таком случае, почему Вы утверждаете, что минимальная адресуемая единица памяти определяется применяемым в языке типом, а не устройством памяти (которая в большинстве архитектур всё-таки адресуется побайтово)?
Я с таким не сталкивался.
«char в Rust представлен не одним байтом, а четырьмя»
А я хоть что-то говорил про char?
Я привел пример того, что намечается тенденция к увеличению минимального размера адресуемой памяти.
То есть в архитектуре x64 (наиболее применимой в массово продаваемых ПЭВМ, насколько я понимаю) тот же u8 из Rust уже реально занимает больше восьми бит, по Вашим сведениям?
Я никак не могу сделать так, чтобы вы один и тот же вопрос не задавал по нескольку раз.
Я вам уже отвечал, что у меня не было потребности в использовании непосредственных адресов.
По rust у меня есть справочник и я даже написал на нем несколько небольших процедур, но я не знаю где его вообще можно применить.
Так же как и языки D и F#.
С# знаю, но он мне не нравится.
=================
Что касается С++ то я для проверки синтаксиса использую Clang и Visual Code, а для более сложных проектов — Visual Studio.
================
Ассемблер пробовал ну очень давно — не понравился.
Даже не так — не нашел область применения.
А я никак не могу добиться от Вас ответа: адресация в программах, скомпилированных из C++ и из Rust, разная (в первом случае минимальная единица — short, каким бы он ни был, во втором — 8 бит), или в обоих случаях адреса доступны с точностью до байта? Если Вы этого не знаете (потому что «не было потребности») — это тоже вполне можно было бы сказать прямым текстом, а не заставлять нас угадывать ответ, исходя из того, что Вы всё-таки знаете, о чём говорили чуть выше.
Так я так и сказал — НЕ ЗНАЮ.
Но это не значит НЕ МОГУ УЗНАТЬ.
=====================
«Некоторые вещи мы не понимаем не потому, что не можем понять, а потому, что они не входят в круг наших интересов».
====================
Я же не на сайт сантехников пришел.
Прошу прощения, здесь мой недосмотр. Хотя, честно говоря, мне сложно представить, что какой-то бинарник может быть принципиально недостижим для C++, учитывая, что Clang его прогоняет через ту же самую LLVM, что и Rust, ну да ладно, нюансов работы этой самой LLVM я сам не знаю.
Я тоже не знаю — использую «clang-cl».
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Ну это уже детали, размер у них одинаковый.
Окей. То есть Вы исходите из того, что полезнее будет считать байт равным 8 восьмеричным цифрам, чем 8 двоичным?
Нет, это совсем из другой плоскости.
Байт двоичных цифр дает нам 256 комбинаций.
А байт восьмеричных цифр — 16 777 216 комбинаций.
То есть вы вообще не только логику не знаете, вы вообще ничего не знаете.

Да куда уж мне… )))))

А теперь посчитайте количество комбинаций при двух значения и при восьми

unsigned long long largerThanlnt = 70000000000;

OCT 1011424636000: 13 pos
BIN 1000001001100010100110011110000000000: 37 pos

А зачем я это должен был подсчитать? Доказать что должно было? ;)

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

Были с троичной — на ВОЗДУШНЫХ триггерах, на электрических не получились.
Любой «недосмотр» программиста или программный сбой — это и есть «логический парадокс», который нарушает логику.
А если «так было задумано» — есть предусмотренный выход из бесконечного цикла.
Вы не путаете логический парадокс и нарушение бизнес-логики? Нарушение бизнес-логики логическим парадоксом не является, поскольку в нём нет внутреннего противоречия. Есть внешнее, а именно — противоречие требованиям.
Я вообще не понимаю как можно заниматься программированием и при этом понятия не иметь о том, что такое ЛОГИКА.
Давайте тогда сделаем так. Раз мы «понятия не имеем», о чём Вы говорите, пожалуйста, приведите используемое Вами определение логического парадокса. Если оно окажется не совпадающим с общепринятым в научной среде — это автоматически закроет вопрос, как сводящийся к «спору о словах». Если совпадёт — можно будет разбираться, какие из высказанных в этой ветке утверждений с этим определением согласуются.
Я его уже приводил, а вот вы пытаетесь подменить понятия логического парадокса «невнимательностью программиста».
«Парадокс в логике — это противоречие, имеющее статус логически корректного вывода и, вместе с тем, представляющее собой рассуждение, приводящее к взаимно исключающим заключениям». Окей, давайте исходить из этого. Какие взаимно исключающие утверждения возникают в ситуации, в которой программа исполняет бесконечный цикл?
Начнем с того, что ваше несогласие с моими словами не означает вашей правоты.
А дальше — любая программа является реализацией некоего логически непротиворечивого алгоритма.
То есть первые логические парадоксы или противоречия могут возникнуть уже на стадии проектирования алгоритма.
Следующие — на стадии его программной реализации.
Таким образом, если программа не делает то, чего от нее ожидают значит в ней есть ЛОГИЧЕСКИЕ ОШИБКИ.
Именно логические, потому что синтаксические отслеживаются допустим в MS Visual Studio прямо в процессе ввода.
Ответа не будет, ясно. Если что, «логическая ошибка» (названная Вами) и «логически корректный вывод» (из приведённого Вами определения парадокса) сочетаются, насколько я понимаю, достаточно плохо.
А как вы относитесь к тому, чтобы просто почить любой учебник Логики?
Любой «логический парадокс» основан именно на «логической ошибке».
Вы сами приводили в пример «парадокс лжеца» — укажите ошибку, на которой он был основан.
В математической логике парадокс лжеца описывается следующим образом

ꓯa a <=> ꓶa
Я правильно понимаю, что применять математическую логику — это логическая ошибка? Другого ответа в Ваших словах, к сожалению, не видно.
То есть вы не понимаете, что означает эта запись?
Ну да ладно, придется объяснять безграмотным
============
Для всех «а» существуют такие «а» для которых верно высказывание «0 = 1».
Я всё ещё жду ответа на вопрос, в чём заключается логическая ошибка, приводящая к парадоксу. А заодно, раз уж так получается, доказательство эквивалентности Вашей формулировки классической: «Данное утверждение ложно».
А вы заметили, что практически не поняли ни одного слова из того, что я вам сказал?
И что виной тому ваша абсолютная безграмотность?
Давайте определим уровень вашей неграмотности.
Итак, вы не знаете:
— логику во всех формах;
— комбинаторику;
— системы счисления,
— что такое алгоритм и так далее.
А вы не могли бы сказать ЧТО ВЫ ЗНАЕТЕ, чтобы я подстроился под ваш уровень знания?
Боюсь, это будет затруднительно, как минимум потому, что никакая подстройка под чужой уровень не научит Вас прямо отвечать на прямо заданные вопросы.
Каким образом можно «прямо» отвечать на вопрос, на который уже не один раз ответил, но вы банально его не поняли.
У Роберта Шекли есть рассказ «Ответчик» — рекомендую.
Еще раз, «логический парадокс» появляется благодаря «логическим ошибкам».
Например, логический парадокс в виндовс — «синий экран смерти», но ведь к его появления привела «логическая ошибка» в какой-то программе.
Tertium non datur.
логический парадокс в виндовс — «синий экран смерти»,

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

Какие взаимно исключающие утверждения содержатся в «синем экране смерти»?
Мы опять говорим о разных вещах.
Вы имеете в виду абстрактные умствования.
А ведь и железо и софт конкретные вещи, у которых должно быть видимое проявление того же логического парадокса, например, крах системы.
А вот действие вирусов могут привести и логическим парадоксам железа, после которого оно превращается в хлам.
Я имею в виду то понятие, которое Вы выше назвали логическим парадоксом, не более и не менее. И да, меня интересует не видимое проявление, а соответствие заявленному.
Я посчитал про себя всех баранов которых смог вспомнить.
И получилось вот, что минер перерезал не тот провод при разминировании.
А синий экран — означает взаимоисключающие рассуждения программиста о взаимодействии ОС и его прграммы.
А синий экран — означает взаимоисключающие рассуждения программиста о взаимодействии ОС и его прграммы.

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


И вообще, BSOD сам по себе достаточно логичная штука: случилась фигня, и система об этом честно докладывает.


А так… Переходил дорогу на красный свет (подумал, что сейчас пронесет). Сбила машина. Парадокс, однако, по вашему получается.

Такое впечатление. что я разговариваю сантехниками
=============
Причина — «логическая ошибка» в ПО.
Следствие — крах системы или «логический парадокс».
Все остановимся на этом.

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


А синий экран — означает взаимоисключающие рассуждения программиста о взаимодействии ОС и его прграммы

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


Только в части случаев BSOD является следствием "логической ошибки в программе".
Даже если принять вашу странную точку зрения, что "логическая ошибка в программе" автоматически вызывает парадокс, то сам BSOD — не является парадоксом, а логичным сигналом системы о его наличии (да, именно так задумывалось поведение системы, и именно для того в систему вводился BSOD — сигнализировать о случившейся проблеме, которую не исправить силами ОС, и которая может привести к еще большим проблемам).


Но, возвращаясь к связке "логическая ошибка" — "неизбежный парадокс".


Определение логического парадокса гласит:
"Логический парадокс — это противоречие, имеющее статус логически корректного вывода".
Но в большинстве случаев логическая ошибка приводит не к парадоксу, а к логически некорректному выводу.

Не подскажите для чего вы пишете столько слов?
Возьмем еще один логический парадокс — буриданов осел.
Осел стоит перед двумя копнами сена, расстояние до которых совершенно одинаковое.
Какую копну сена он выберет — левую или правую?
Существует целый класс «логически-неразрешимых» задач.
Но неразрешимые они только в рамках ДВОИЧНОЙ логики.
В жизни осел не умирает с голоду.
Отсюда два вывода:
— осел не пользуется логикой — нонсенс;
— осел пользуется НЕ ДВОИЧНОЙ логикой.
Следовательно, Природа не использует двоичную логику.
Осел пользуется инстинктами. Называть их не двоичной логикой — это достаточно большая натяжка )
А как вам такая идея.
Деньги — это ИИ с триадной логикой.
Три логических полюса Денег — Кредиторская Задолженность, Наличные Деньги, Дебиторская Задолженность.
Их же можно рассматривать как «формы существования» Денег.
Движение Денег осуществляется в виде смен «форм существования».
Человечество является эффектором Денег.
Можете хотя бы примерно прикинуть «тактовую частоту» этого ИИ — сколько транзакций происходит в Мире каждую секунду?
www.bis.org/cpmi/publ/d107.htm
смотря что именно вы имеете ввиду под деньгами и под транзакциями — там имеет место быть достаточно много всяческой статистики. Но, в любом случае, даже если под деньгами понимать только то, чем в данный момент человек расплатился за кофей, и взять среднепотолочного человека, который оплатил проезд на работу, обед, и проезд обратно (что, в общем, не правильно) — то выйдет 7млрд * 3 / 24 / 60 / 60 — около 300к транзакций.
А если сюда прибавить весь тот ужас, который происходит в момент контакта кредитки с терминалом… А еще вспомнить за всякие биржи… А еще посмотреть в сторону блокчейнов (которые, правда, уже совсем условно деньги, но рапортуют о миллиардах транзакций в секунду)…
Нет, не только то чем за кофей, вообще все, что так или иначе связано с Деньгами.
Ту же электроэнергию, те сервера и так далее.
Мы же без денег уже и шагу ступить не можем.
Представим на мгновение что Деньги исчезли.
Представим на мгновение что Деньги исчезли.

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

Вообще то исчезновение денег будет катастрофой по страшнее атомной войны, но к этому все идет — не зря все страны кинулись делать золотые запасы.
=============
Но я о другом, о том что Деньги являются ИИ, а люди его эффекторами.
Деньги используют природную триадную логику ему подчинены все компьютеры на Земли и вообще все существование Человечества.
Деньги являются ИИ, а люди его эффекторами.

Понятие ИИ предполагает принятие решений. Деньги решения не принимают.


Деньги используют природную триадную логику

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


ему подчинены все компьютеры на Земли и вообще все существование Человечества.

Кому "ему"?

Деньги решения не принимают.

Два вопроса:
— что такое ИИ
— что такое «принимать решение»
==============
Триадная логика — такое же изобретение человечества

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

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


Человеческая триадная и вообще н-мерная логика предполагает равноценность всех логических полюсов.

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

ИИ, если использовать традиционную расшифровку аббревиатуры — искусственный интеллект.

А что такое «искусственный интеллект»?
Это Скайнет и ничего кроме?
Что такое «принимать решение» в данном контексте не важно.

А если вы просто не можете понять, что решения принимаются?
Как вы логику нарисуете

Нарисовали — как совокупность двумерных логик.
проста как пять копеек

Как раз тот случай когда «простота хуже воровства» — цветной мир низвели до черно-белой фотографии. Даже серого цвета нет.
цветной мир низвели до черно-белой фотографии. Даже серого цвета нет.

Видимо, человеческий глаз воспринимает гораздо более узкий спектр частот и гораздо меньший диапазон интенсивностей, чем органы зрения Вашего вида, раз трёхбайтная цветовая схема для Вас выглядит чёрно-белой. К сожалению, это различие на нынешнем уровне развития биотехнологий принципиально неустранимо.
Вам не кажется, что вы за иронией пытаетесь скрыть узость мышления?
Речь идет о логиках — н-мерная логику представляют как совокупность двумерных.
В с++ такое называется свертка
правая свертка — ((((1 + 2) + 3) + 4) + 5
левая свертка — (1 + (2 + (3 + (4 + 5))))
Так я её и не скрываю. Доступного нам мышления вполне достаточно, чтобы понять, что для Вас (и для Вашего вида) оно заведомо будет слишком узким. Ну, если, конечно, осознать, насколько развитым является Ваш вид, но это из других веток диалога было достаточно очевидно, по крайней мере, с моим опытом.
Ну допустим, я с вами разговариваю как с ребенком — меня не задевает ваша ирония.
А с какой целью вы со мной разговариваете?
По большей части просто фиксируя заинтересовавшие меня особенности и, возможно, ожидая поправок, если где-то увидел их некорректно. Прошу прощения, если Вас это отвлекает.
Нет, не отвлекает — ваша «ирония» это скорее «подростковая агрессия» на непонятные вам слова.

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

с приемлемой точностью

это ключевое слово.
Только вот к логике оно неприменимо.

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


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

Вполне применимо

Смотря для чего «применимо».
Например, для создания ИИ совсем неприменимо.
на нечеткой логике

«Нечеткая» является вполне «четкой двоичной» только замаскированной.
а в специализированных

В с++ такое называется свертка
правая свертка — ((((1 + 2) + 3) + 4) + 5
левая свертка — (1 + (2 + (3 + (4 + 5))))
Проблема в том, что в природной логике логические полюса НЕРАВНОЦЕННЫ.
Например, для создания ИИ совсем неприменимо.

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


«Нечеткая» является вполне «четкой двоичной» только замаскированной.

Если вам не нравится нечеткая логика (хотя она рядом не валялась с "четкой двоичной"), есть еще вероятностная.


а в специализированных

В с++ такое называется свертка

А какая связь у специализированных компьютеров, использующих нечеткую логику (обычно именуемых нейросетями и построенных на искусственных нейронах) и у вашей формулы свертки?


Кстати, в сверточных нейросетях свертка выполняется совсем не так.


Проблема в том, что в природной логике логические полюса НЕРАВНОЦЕННЫ.

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


Кстати, возвращаясь к бедному абстрактному ослику.
Если рассматривать его поведение в бинарной логике, то его поведение будет определяться просто:
Если левая копна ближе, то есть ее, иначе есть правую. Или наоборот, любое решение прокатит. Главное, при равном расстоянии прошить четкое решение в любую из сторон.
В реальной природе же проблема выбора между двумя равноценными объектами решается просто.
Либо жесткой прошивкой одного из вариантов (один всегда будет справа или слева, снизу или сверху, спереди или сзади), либо "киданием монетки" (задействованием любого ГСЧ, сиречь случайного процесса), либо "пусть один ослик сдохнет, на всю популяцию это не окажет никакого влияния, поскольку ситуация абсолютно равнозначного выбора очень маловероятна".

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

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

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

В основе все равно двоичная — у нас нет недвоичных процессоров.
Кстати, в сверточных нейросетях свертка выполняется совсем не так.

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

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


В основе все равно двоичная — у нас нет недвоичных процессоров.

Там не всегда процессоры.


Вероятность — это мера нашей безграмотности.

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

Там не всегда процессоры.

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

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

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


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


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

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


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

Ну-ну

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

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

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

Есть еще и нечеткая логика: не как в бинарной логике — 0 и 1, а значения на отрезке [0; 1]. Живые нейроны работают по нечеткой логике. Зато в синтетических нейросетях значительно чаще используется двоичная логика в силу упрощения и уменьшения объема вычислений, и значительно реже — нечеткая логика с заданной дискретизацией. Проводятся также эксперименты по построению нейросетей на аналоговых элементах и на живых нейронах, изъятых из мозга животных.
Есть еще и нечеткая логика

Есть много чего — эвристика, нечеткая логика, неформальная логика, н-мерная логика.
Проблема только одна — все они в итоге сводятся к двоичной логике.
Живые нейроны работают по нечеткой логике

Нет. Я и пытаюсь донести до вас, что «все существующее» подчиняется той же логике, которая наглядно просматривается в «задаче о двух паровозах»
Она триадная, но неравноценная — ("+" — "~" — "-").
Трех полюсная, но НЕ ТРЕУГОЛЬНАЯ.
что «все существующее» подчиняется той же логике, которая наглядно просматривается в «задаче о двух паровозах»

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

Например — преобразования нейтрон-протон и обратно

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

Логика «задачи о двух паровозах» не модулируется в двоичную.
Группа «свободных» вагонов является ПЛАВАЮЩЕЙ — она КОЛЕБЛЕТСЯ нивелируя попытки войти в резонанс, в первую очередь.
Ее поведение МОЖНО СРАВНИТЬ с нечеткой логикой, но это всего лишь СХОЖЕСТЬ, основанная на том факте, что ее колебания носят «нечеткий» характер.
На самом деле — это РЕАКЦИЯ на «внешние раздражители».
Группа «свободных» вагонов является ПЛАВАЮЩЕЙ — она КОЛЕБЛЕТСЯ нивелируя попытки войти в резонанс, в первую очередь.

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

Скорее три континуума — растянутые, свободные, сжатые.
Только один нюанс — они возникают только В ДВИЖЕНИИ.
В растянутых и сжатых континуумах возникают «волны состояний», которые гасятся в свободном.

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


Но относительно самой двоичной логики это не имеет значения. Двоичная логика придумана не для разрешения парадокса про осла имени одного известного человека. Она придумана для построения математической модели логики.
А в компьютерной технике она была использована даже не в тех целях, в которых была изначально задумана, т.е. не для для описания логики вообще, а для проведения банальных математических вычислений в рамках булевой алгебры, что позволило производить уже нормальные арифметические вычисления за счет реализации приблизительной модели, описывающей обычную математику через булеву алгебру.
Уровень логики программиста как правило находится вообще вне бинарной логики компьютера, поскольку он как правило оперирует не булевой алгеброй, на которой базируется компьютер, а уровнем языка программирования (даже если это ассемблер).
Конечно, почти в каждом ЯП есть операции двоичной логики. Но используются они далеко не всегда и не являются основой ЯП. Это всего лишь операции булевой алгебры, которые программист может использовать наряду с другими средствами для описания своей модели.
Более того, как показывает практика, некоторые программисты даже не догадываются о наличии подобных операторов в своем любимом языке, а остальные почти не используют их.
Если программист допускает логическую ошибку, то он допускает ее в своей модели той предметной области, поведение которой он пытается описать своей программой, или в процессе перевода описания поведения модели в вид программы.
Если в голове программиста возникли парадоксы, которые он заложил с в своей модели и описал в программе, то это не парадоксы программы и компьютера. И они никак не связаны с самим процессом написания программы, с ЯП и с процессом исполнения программы на компьютере.
При этом на уровне исправного компьютера (любом его уровне) вообще никаких логических ошибок и парадоксов не имеется по определению. И если программист "сказал" компьютеру "какую-то чушь", то компьютеру не холодно и не жарко. Компьютер просто тупо выполнит то, что написал ему программист, произведя все действия, полагающиеся при выполнении программы. Если в ОС написано, что правильным действием при выполнении такой программы будет синий экран, то компьютер, исполняя строго код самой ОС, покажет синий экран. Если программист вольно или невольно описал бесконечный цикл, то будет исполняться бесконечный цикл.

Природа (как нечто целое) вообще не использует логику. Вообще никак не использует.

В качестве примера «природной логики» возьмите «задачу о двух паровозах».
Логика, которая там ИСПОЛЬЗУЕТСЯ присутствует во всем ЧТО СУЩЕСТВУЕТ.

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

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

То есть вы утверждаете, что сначала человек создал логику и только потом Природа стала ее использовать?
А до того как Аристотель ее создал логики в Природе не было?
И все же как у нас дела с «задачей о двух паровозах»?
То есть вы утверждаете, что сначала человек создал логику и только потом Природа стала ее использовать?

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


А насчет паровозов, это что за задача такая? Гуглится только задача на тему паровозов, которые надо столкнуть, написав для них программу.

Странно, вчера мне сказали, что нашлась.
Ладно, есть достаточно длинный и тяжелый железнодорожный состав, который не под силу одному паровозу. Тогда к составу СЗАДИ прицепляют второй.
Но тут, с точки зрения двоичной логики, возникает логическая ошибка — один тянет — растягивает, а другой — толкает, сжимает.

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

И какое отношение это имеет к двоичной логике?

К двоичной НИКАКОГО.
Там природная, триадная, нечеловечская.
В процессе движения образуется ТРИ группы вагонов — сжатые, свободные и растянутые.
Еще раз, «логический парадокс» появляется благодаря «логическим ошибкам».

Но не всякая логическая ошибка приводит к парадоксу.

Давайте определимся в конце концов, мы специалисты в области матлогики и нас не интересует ничего кроме нее самой.
Или же нам нужно практическое ее применение.
Вот пчелы строят соты — у них есть логика?
Не важно какая или они вообще ведут себя нелогично как «пьяная обезьяна за печатной машинкой».
Как все запущено… )))

Для всех «а» существуют такие «а» для которых верно высказывание «0 = 1».

Это же надо привести формулу и самом не уметь ее прочитать! Ваше выражение читается как «любое выражение является истинным в случае если оно ложно и наоборот».

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

Во-вторых, это все не имеет отношения к булевой алгебре. Грубо говоря, в булевой алгебре нет таких а! )) Поэтому выражение ложно.
UFO just landed and posted this here
ꓯa и ꓱa — кванторы всеобщности и существования.
Я уже говорил о них, ну да ладно — повторение мать учения.
Квантор существования обозначается ꓱa — можно озвучить как «существует хотя бы один».
Квантор всеобщности обозначается ꓯa — можно обозначить как двойное отрицание — «не существует ни одного».
Каким образом их можно употреблять вместе?
Далее, любое суждение не может быть «правильным» или «не правильным» — оно или истинно или ложно.
Выражение «я являюсь своей противоположностью» — это всего лишь ВЫРАЖЕНИЕ.
UFO just landed and posted this here
Двоичная логика не является расширяемой: ее аксиоматика задана жестко и все последующие предположения проверяются на истинность с использованием этой аксиоматики.

Приведенная вами запись является ложным утверждением с точки зрения булевой алгебры. Это отнюдь не парадокс.
Вот интересно, если человек не понимает того о чем говорит, то он кто?
Любое утверждение либо ИСТИННО, либо ЛОЖНО.
Парадокс лжеца — это ВСЕГДА ЛОЖНОЕ утверждение.
Что и отображает моя запись.
Может быть вы все таки почитаете учебник, чем городить ерунду?
Пардоньте, но парадокс лжеца не истинное, и не ложное утверждение. Было бы это чем-то определенным (тем же ложным), то не было бы и парадокса.
Вы разбираетесь в математической логике?
Вот выше я описал в ее терминах именно парадокс лжеца.
Понять можете?
Его и нет. Парадокс лжеца является парадоксом исключительно в рамках наивной теории множеств. Для формальной булевой алгебры он является ложным утверждением/предположением.
Честно говоря, даже не очень понимаю, как можно это утверждение правильно записать в рамках формальной логики. Ведь А <=>! А больше похоже на утверждения «Рыцарь является лжецом» или «Лжец является рыцарем», которые, естественно, ложны.
Эм… Нет.

Знак <=> не имеет отношения к «является»(∈) и к равенству(=) тоже. Это взаимное следствие, эквивалентность. Можно сформулировать как «выражение является истинным в случае если оно ложно и наоборот». Этот знак подходит для парадокса лжеца, если конечно не впихнуть туда еще квантор общности ꓯa, что читается как «для любого а»! ;) Т.е. любое выражение является истинным в случае если оно ложно и наоборот! ))) Это уже не парадокс лжеца, а буддизм какой-то! Типа все в мире равнозначно и потому не имеет значения.
Да, точно, про эквивалентность накосячил с формулировкой)
Т.е. можно записать так: ((a <=> 1) -> (a <=> 0)) & ((a <=> 0) -> (a <=> 1))?
Да вы усложняете… a <=> 1 фактически значит что «а» всегда истинно, вне зависимости от а. Без кванторов это странно, да и с кванторами так себе: Не ясно зачем "<=>", когда можно просто "=". Уж лучше исходное, которое WladWlad привел, только без квантора общности (с квантором существования): ∃a a <=> ꓶa
Парадокс в логике — это противоречие, имеющее статус логически корректного вывода.

В вашем случае нет никакого корректного вывода — есть просто некорректное тождество и все.

Вы могли бы просто записать true <=> false, и объявить это парадоксом — эффект был бы тем же.
Найдите какой-нибудь учебник по математической логике и прочитайте что такое «квантор всеобщности».
Я бы рекомендовал вам просто хоть какой-нибудь учебник… )))))
Чуть выше был задан вопрос, который Вы проигнорировали. Классическая формулировка (не в терминах матлогики) парадокса лжеца звучит как «Данное утверждение ложно». Покажите её эквивалентность Вашей формулировке с квантором всеобщности, если Вы утверждаете, что она тоже верна.
Парадокс жреца без матлогики звучит так — «Я лгу».
И парадоксальность его в том, что ложью является любая его оценка хоть «истина» хоть «ложь».
Именно об этом и говорит квантор всеобщности.
Если квантор существования можно озвучить так — «существует хотя бы один».
То квантор всеобщности можно заменить двойным отрицанием — «не существует ни одного».
Возвращаясь к лжецу получаем — «Не существует ни одного истинного варианта для выражения 0 = 1».
Окей, но теперь — где, всё-таки, здесь «рассуждение, приводящее к взаимно исключающим заключениям»? Заключение у Вас вполне однозначно, и Вы его изложили в последней фразе. Получается, то, что Вы назвали, — не парадокс?
Есть суждение, которое мы можем оценить либо как «истина» либо как «ложь».
Оценка, суждение, заключение в данном случае парадоксально тем, что ложна возможность сделать такое заключение.
Если рассматривать его с точки зрения булевой алгебры его оценка лежит ВНЕ множества возможных оценок.
Понял, благодарю. А теперь вернёмся чуть раньше: где в Ваших рассуждениях (описывающих парадокс лжеца) была логическая ошибка?
У меня не было ошибок — не я его придумал.

Уважаемый, а вы вообще в курсе, что ЛПП непротиворечива, а значит, в ней невозможно вывести утверждение, которое будет ложно в какой-либо интерпретации?

Теорема Геделя утверждает, что невозможно непротиворечиво описать систему находясь внутри нее.
Теорема Геделя утверждает, что невозможно непротиворечиво описать систему находясь внутри нее.

Нет, теорема Геделя этого не утверждает, она утверждает несколько иное (ну, совсем иное, если уж прямо говорить).


К слову, теорема, утверждающая непротиворечивость логики первого порядка — это тоже теорема Геделя. Просто другая. Та, про которую вы говорите (неправильно говорите) — это теорема Геделя о неполноте, а та, про которую говорю я — это теорема Геделя о полноте.


Вот такие вот дела ;)


К тем кто их прочитал еще тогда когда другие пешком под стол ходили.

Видимо, в этом и проблема. Давно читали. Вот и про теоремы Геделя забыли уже за давностью лет. Перемешалось в голове все.
Возможно, следует освежить память :)

Ну да, ну да — «О неполноте формальных оснований арифметики».
В таком случае зачем нам обработка исключительных ситуаций, если ошибок не бывает?

А при чем тут обработка исключительных ситуаций?

А у нас программный код логике не подчиняется?

Допустим. В этом контексте — при чем тут обработка исключительных ситуаций?

Потому, что я уже не знаю в каком ключе с вами разговаривать.
— Программный код — это логика?
— «Допустим».
— Ошибки в программном коде логические?
— «Это невнимательность прграммиста».
— Неработающая или криво работающая программ это логический парадокс?
— «Нет двоичная логика не допускает парадоксов».
==============
Блин! Пчелы не используют обработку искючительных ситуаций.

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

Если я сделал в коде опечатку

Значит существует возможность сделать ошибку — это само по себе уже является парадоксом.
Значит, любой язык программирования, существующий сейчас и способный существовать в будущем, содержит в себе парадокс?
Это не предположение — это закон.
А название этого парадокса — человеческий фактор.
Не, с тем, что люди — очень странные и глупые животные, я не спорю, но к чему тогда вообще было начинать весь этот разговор? Парадоксы (в Вашей формулировке) из жизни человечества в принципе никуда не могут деться, и то, что «двоичная логика» ими «напичкана» (цитирую Вашу первую фразу в этой ветке) — никакого значения уже не имеет, раз слабое место — это именно люди.
Давайте зайдем с другой стороны — откуда вообще взялась дуальная логика?
Ее придумал Аристотель для борьбы с софистами.
А теперь с третьей, если бы он не был учителем Александра Македонского, то о нем бы вообще никто не знал.
И с четвертой, ни одно утверждение Аристотеля при проверке не оказалось истинным.
Почему же мы его Логику считаем правильной.
Так и Аристотель, и софисты, и все прочие явно и неявно перечисленные Вами — люди. То есть, человеческий фактор работал всегда, есть ли у нас дуальная логика или нет. Зачем её вообще было сюда тащить (Вам в этот разговор, в смысле), если и без неё всё плохо?
Зачем её вообще было сюда тащить

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

Совершенно неверное утверждение — Природа существует прекрасно без человека.
====================
Кстати, не все что создано человеком создано по законам двоичной логики.
Еще точнее, только все, что связано с вычислениями.
====================
Сегодня я привел пример «нечеловеческой» логики — «задача о двух паровозах».
Окей — в любой логике, которая может применяться для построения программного обеспечения (разговор был, насколько я помню, именно в этом контексте). Ну, если, конечно, мы не поручим это самое построение программного обеспечения какому-либо иному биологическому виду, который никакого аналога «человеческого фактора» в свои действия не вносит. И да, что нечеловеческого в этой задаче, если она построена людьми?
Ладно, уточняю — вы знаете что такое «задача о двух паровозах»?
До этого разговора не знал даже названия. Яндекс подсказывает, что в ней описывается состав, который должен быть частично растянут и частично сжат (а частично, возможно, недеформирован вовсе), чтобы передний паровоз его тянул, а задний — толкал. Вы это имеете в виду? И Вам не нравится, что при буквальном применении бинарной логики к объекту, состояние которого заведомо описывается более чем одним битом информации, получается ерунда?
Ну раз вы теперь знаете о чем разговор, я приведу решение.
«В центре состава возникает группа вагонов, которые и не сжаты и не растянуты. Отдельные вагоны этой группы присоединятся то к растянутым, то к сжатым».
=================
Мы имеем наглядный пример триадной логики:
— растянутые "+"
— нейтральные "~"
— сжатые "-"
Давайте для начала ОСОЗНАЕМ этот факт.
Мы имеем наглядный пример системы, которая описывается более чем двумя состояниями (растянутый, сжатый, недеформированный), совершенно верно. Что здесь нечеловеческого, собственно? Может, моё сознание настолько изменено курсом механики сплошной среды, что некоторые очевидные для меня моменты на самом деле нечеловеческие?
Так, теперь та же задача, но в двоичной логике — парадокс «буриданов осел».
Отбросьте «конкретное» и перейдите на «абстрактный» уровень.
В каком месте, пардон, она в двоичной логике? У осла тоже три состояния. Другой вопрос, что одно из них очевидно менее выгодно, но это уже конкретика, которой в другой задаче подобного рода может и не быть.
Нет. У осла только два состояния — правое или левое.
Вот здесь как раз «закон исключенного третьего».
Отбросьте конкретное (невыгодность стоять на месте), оставьте только факт: состояние «стоять на месте» в этой задаче тоже существует.
Нет. Здесь только вопрос выбора — правое или левое.
Отбросьте конкретное — осла.
Окей, допустим. Я всё ещё жду ответ на вопрос, что нечеловеческого может быть в задаче, созданной человеком, но допускаю, что Вы меня к нему подводите постепенно.
Итак, в человеческой то есть в двоичной логике, задача является логически неразрешимой — парадоксом.
Парадоксы они тоже делятся на группы.
Почему?
Потому, что осел СТОИТ.
Причем это не статическая система — это вообще не система.
Все мгновенно бы поменялось начни осел двигаться — в движении практически невозможно достичь идеального равновесия.
===============
Перейдем к паровозам — пока состав неподвижен там тоже нет системы — набор ничем не связанных элементов.
А вот когда он начинает двигаться, то возникает система.
Причем не просто система, а САМОРЕГУЛИРУЮЩАЯСЯ СТАБИЛЬНАЯ система подчиняющаяся законам триадной НЕЧЕЛОВЕЧЕСКОЙ логики.
Ну что там человеческого?
Что главное в ней для нас?
САМОРЕГУЛИРУЕМОСТЬ — нет надобности в «обработке исключений».
в человеческой то есть в двоичной логике

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

Компьютеры построены на двоичной логике, но используются в них она не по назначению.
Точнее, используется даже не сама двоичная логика, а двоичная алгебра — строгая математическая дисциплина, вводящая набор значений — 0 и 1 (истина и ложь) и набор операций над ними.
А используют ее в общем не для операций над отдельными значениями "истина" и "ложь", а для моделирования математических вычислений, которые в итоге и используются для выполнения любой программы.
Есть только два случая, когда в программах применяется булева алгебра непосредственно (не двоичная логика, а именно булева алгебра). Это условия ветвления и битовые операции.
Причем даже для организации ветвления в программах далеко не всегда используются средства булевой алгебры.

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

В 1977 году в Ною-Йорке произошла авария городской энергосети.
Причиной послужил пик МИНИМУМА потребления — энергосеть, состоящая на тот момент почти из одних реле, сработала именно как логическая система, в которой возникла логическая ошибка, приведшая к логическому парадоксу — аварийному отключению.
===============
Любой ЯП в том числе и Ассемблер скрывает двоичную суть Компьютера.
Однако если вспомнить, что ЦП может только складывать и вычитать, то все возвращается на свои места.
Причиной послужил пик МИНИМУМА потребления — энергосеть, состоящая на тот момент почти из одних реле, сработала именно как логическая система, в которой возникла логическая ошибка, приведшая к логическому парадоксу — аварийному отключению.

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

Причинами зависти Запада к СССР было две вещи — ГОСПЛАН и Единая система энергоснабжения.
Причины в виде «молний» были придуманы намного позднее как отмазки.
Все здания ЗАЗЕМЛЕНЫ.
И для энергосистем намного страшнее НЕ МАКСИМУМЫ, а МИНИМУМЫ.

Какое отношение отсутствие единой системы энергоснабжения имеет к срабатыванию систем защиты?


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


И для энергосистем намного страшнее НЕ МАКСИМУМЫ, а МИНИМУМЫ.

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

Молнии попадают В ГРОМООТВОДЫ а не в здания.
При максимумах срабатывает недополучают потребители.
А вот резкий скачок равносилен разрушению плотины.

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


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

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

Молнии, даже при наличии громоотводов, вполне исхитряются попадать в здания.

Исходя из личного опыта никогда с таким не сталкивался. По-моему эта задача была решена еще Ломоносовым.
они устраивают наводки

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

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

В том то и проблема — в США нет единой энергосистемы, а существующие являются частной собственностью.
Исходя из личного опыта никогда с таким не сталкивался. По-моему эта задача была решена еще Ломоносовым.

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


На тот момент использовались в основном реле — электро-механические устройства, им по фигу «наводки».

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


То есть на поставщиках никак не сказывается.

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


В том то и проблема — в США нет единой энергосистемы, а существующие являются частной собственностью.

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

А я сталкивался.

Это надуманная ситуация — в нашей стране миллионы километров ЛЭП под открытыми небом и сотни тысяч подстанций, но ничего подобного никогда не было.
это достаточно сложные процессы

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

Вы имеете срабатывание аварийной защиты после удара молнии? Было, очень даже было.
Например, 3 июля 2018 года микрорайон в Красноярске остался без света и воды после того, как разряд молнии ударил в опору линии электропередач.


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

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

О том, что минимумы страшнее максимумов стали задумываться довольно давно — создавал аккумуляторы, которые заряжали во время минимумов.
Одним и оригинальных было создание искусственного водоема, который закачивалась вода во время минимумов.
А использовалась во время уменьшения естественных осадков.
Вы имеете срабатывание аварийной защиты после удара молнии? Было, очень даже было.
Например, 3 июля 2018 года микрорайон в Красноярске остался без света и воды после того, как разряд молнии ударил в опору линии электропередач.

Очень интересный случай произошел во время моей службы в армии. Выехали мы тогда на танковое стрельбище. На следующий день пошел дождь, и разразилась сильная гроза. И вот сидим втроем как-то вечером в окопе под навесом, наблюдаем за грозой. И вдруг у меня в голове что-то «дернуло», и я говорю, что сейчас молния ударит вон в тот столб (показал рукой на опору ЛЭП в километре от нас, а то и дальше). И секунд через 10 как жахнет сильнейший разряд молнии, и именно в эту опору ЛЭП! В результате мы дня 3 сидели без света и без дела, ожидая, когда починят электричество, без которого не могло быть танковых стрельб (движение мишеней, подсветка, освещение и т.д.), да и все населенные пункты вокруг полигона остались без света.
как жахнет сильнейший разряд молнии, и именно в эту опору ЛЭП

Теперь смотрим — опора имеет громоотвод и заземление, провода висят на изоляторах. Все это рассчитано исходя из геофизических данных этого района.
Вывод — где-то было допущено НАРУШЕНИЕ проекта.
Короче, был банальный БРАК.
Но я говорю о другом — в 1977 аварийное отключение было по причине резкого ПАДЕНИЯ ПОТРЕБЛЕНИЯ.
В результате энергосеть сработала как логическая система.
Возник логический парадокс наподобии деления на нуль.

Вы глубоко заблуждаетесь.
Любая защита носит вероятностный характер и ограничивается балансом затрат и стоимости/значимости сохраненного имущества.
Никто не будет вкладывать в грозозащиту средства, превышающие стоимость защищаемого имущества или размер предполагаемого ущерба, поскольку дешевле будет устранить последствия воздействия молнии, превысившего возможности грозозащиты.
Более того, защита будет производиться только в рамках приемлемого риска, а не на все случаи жизни.
Сам процесс расчета грозозащиты носит вероятностный характер.
Согласно инструкции по устройству молниезащиты зданий, сооружений и промышленных коммуникаций, которая и используется при расчете грозозащиты (синоним молниезащиты) надежность оной для обычных объектов устанавливается от 0.8 до 0.98, а для специальных от 0.9 до 0.999. Т.е. вероятность повреждения объекта молнией не так уж и мала, чтобы это повреждение было чем-то исключительным.

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

Общая формула для коэффициента запаса имеет вид:

n = S T {\displaystyle n={\frac {S}{T}}} {\displaystyle n={\frac {S}{T}}}

где S {\displaystyle S} S — предельно допустимое значение рассматриваемой величины (силы, напряжения, перемещения и т. д.); Величина получена при механических испытаниях материала.

T {\displaystyle T} T — расчетное значение этой величины.

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

Критерий работоспособности выполняется, если

n > [ n ] {\displaystyle n>\left[n\right]} {\displaystyle n>\left[n\right]},

где [ n ] {\displaystyle \left[n\right]} {\displaystyle \left[n\right]} — минимально допустимый коэффициент запаса.

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

:) Разве?
"Из ложных посылок можно вывести истинное заключение"
0|0=1
| в данном случае не оператор языка С, обозначающий "или", а операция булевой алгебры, именуемая "штрих Шеффера".

:) Разве?

Например, о том что большое тело падает быстрее.

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


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

Вы пример из Логики, а говорю о том, что если ВСЕ КРОМЕ ЛОГИКИ у Аристотеля неверно, почему мы должны считать Логику верной.
Даже то утверждение которое привел ПРИ ОПРЕДЕЛЕННЫХ УСЛОВИЯХ, например в воздухе или в воде, может оказаться ЧАСТИЧНО верным.
Значит существует возможность сделать ошибку — это само по себе уже является парадоксом.

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

Не думал, что НА ЭТОМ сайте мне придется разжевывать банальные вещи. Ну да ладно.
Существует класс «логически неразрешимых» задач.
Но эти задачи НЕОДНОРОДНЫ и разделяются на подклассы.
Соответственно, каждый подкласс являет собой особенный тип «логического парадокса».
Логический парадокс — это НЕРАЗРЕШИМОСТЬ именно в двоичной логике и не более того.
Логический парадокс — это НЕРАЗРЕШИМОСТЬ именно в двоичной логике и не более того.

Неразрешимость чего?

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

А можно пример такого утверждения сформулировать, для которого нельзя сказать, ложно оно или истинно?

Но это не высказывание ЛПП. Высказывание ЛПП — это, например, "WladWlad — лжец".

Вы не привели решения задачи «Я лжец».
Еще одна попытка.
Вы не привели решения задачи «Я лжец».

Вы не привели задачи.
Еще попытка.


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

Ладно, привожу подробную формулировку задачи:
Нужно оценить ложно или истинно высказывание «я лжец».
Вы пытаетесь подсунуть ДРУГУЮ задачу.
Нужно оценить ложно или истинно высказывание «я лжец».

Это не высказывание.

Это не высказывание.

С какой стороны?
Приведите доказательство того, что это «не высказывание».
Приведите определение высказывания, принятое в Вашем родном мире. К сожалению, без этого мы разговаривать с носителями нечеловеческой терминологии и приходить к осмысленным выводам физически не способны.
Для начала, единственной логикой СОЗНАТЕЛЬНО используемой Человечеством является ДВОИЧНАЯ ИЛИ ДУАЛЬНАЯ.
Природа подчиняется ПРИРОДНОЙ И НЕЧЕЛОВЕЧЕСКОЙ логики.
Если вы не понимаете разницы, то у вас НЕТ НИКАКОЙ логики.
«Нечеловеческая терминология» возможна только у БЕЗГРАМОТНОГО ЧЕЛОВЕКА.
Приведите доказательство того, что это «не высказывание».

В высказываниях ЛПП нету аналогов местоимений, в предложенном вами тексте — есть. С-но, предложенный вами текст — не высказывание ЛПП.

ЛПП может означать:

Липопротеины промежуточной плотности (биология);
Линия пересечения плоскостей;
Латвийская первая партия;
Лёгкий понтонный парк;
Лечебно-профилактическое питание;
Лучший представитель породы (титул у собак).
ЛПП-25 — 25-мм лёгкая противотанковая пушка

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

Совершенно верно, они просто продолжают писать в /dev/null и терять мёд через срезанную стенку сот.

Неработающая или криво работающая программ это логический парадокс?

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

Ошибки в программном коде логические?

Смешение понятий «ошибка в последовательности рассуждений» и «ошибка в реализации требований»?
Смешение понятий «ошибка в последовательности рассуждений» и «ошибка в реализации требований»?

Действительно, «умышленное убийство» и «нанесение тяжких телесных повреждений со смертельным исходом» нельзя считать синонимами.
Во втором случае уже как бы и не убийство.
===========
Любая ошибка в программном коде для начала ЛОГИЧЕСКАЯ.
А уже только потом — в каком месте логических построений она произошла.
Действительно, «умышленное убийство» и «нанесение тяжких телесных повреждений со смертельным исходом» нельзя считать синонимами.

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

Любая ошибка в программном коде для начала ЛОГИЧЕСКАЯ.
А уже только потом — в каком месте логических построений она произошла.

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

Нет — это будет «неумышленное убийство», в том случае — НЕ СМОГ убить сразу, умер через час.
====================
где в этой цепочке произошла ошибка?

Это уже из другой оперы — отладка.
===================
В логических построениях есть два метода — анализ и синтез. Их не нужно смешивать.
Нет — это будет «неумышленное убийство», в том случае — НЕ СМОГ убить сразу, умер через час.

Признаю, мог промахнуться с терминологией, УК наизусть не знаю. В любом случае: убийство, но не «умышленное убийство».

Это уже из другой оперы — отладка.

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

В логических построениях есть два метода — анализ и синтез. Их не нужно смешивать.

Процитируйте фразу, в которой я их смешиваю.
Я к тому, что «отмазки» создают юристы — они на них зарабатывают.
======================
Процитируйте фразу, в которой я их смешиваю.

Вы их не различаете.
А неважно, из какой «оперы».
Разумеется, неважно. И то, и другое — методы логических построений. Где-то в этих построениях есть ошибка. В анализе или в синтезе — неважно, в любом случае её можно найти и явно сформулировать.
Анализ, в данном случае — это поиск ошибки.
А синтез — ее исправление.
Причем исправление ошибки может привести к новой ошибке.
Действительно, «умышленное убийство» и «нанесение тяжких телесных повреждений со смертельным исходом» нельзя считать синонимами.

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

а умысла убить не было

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

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

покушение на убийство

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

Имеет.
Это когда жертва осталась жива.

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


Имеет

Разве что в плане возможностей отмазаться: "я не хотел" или "телесные не явились непосредственной причиной смерти".

если не было доказано

В точку — это специально созданные лазейки для адвокатов. Они имеются в каждом законе.
Понятия «ложного обвинения» в вашем мире уже не существует достаточно давно, чтобы его даже как исторический казус не изучали, я так понимаю. Приятно слышать, что хоть один вид разумных существ оказался настолько развит — известные мне случаи не подобрались даже близко.
Вы опять не в тему — я говорю о том, что при создании любого закона умышленно создаются лазейки для адвокатов.
За одно и то же действие можно получить и пожизненное заключение и компенсацию за моральный ущерб.
Любое утверждение либо ИСТИННО, либо ЛОЖНО.
Парадокс лжеца — это ВСЕГДА ЛОЖНОЕ утверждение.

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

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

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

А вы для начала сформулировать это утверждение попробуйте. Так, чтобы оно было действительно утверждением :)

Так а в чем проблема? ;)

«Выражение А является истинным в случае если оно ложно и наоборот».

Или в виде вопроса: Является ли А истиной, если оно ложно?

В обоих случаях такие предположения имеют смысл в системах, где аксиомы могут быть дополнены/изменены. т.е. Где вы не просто присваиваете А значение, а задаете ПРАВИЛО, что конкретное А всегда ложно, когда оно истинно. Полагаю нечто такое возможно в каком-нибудь прологе. И как такое будет отрабатывать — зависит от реализации.

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

Проблема в том, что это "утверждение" нельзя сформулировать в логике высказываний :)


В языке ЛВ есть переменные, символы логических операций и скобки. И все. Там нет равенство, с-но нельзя написать A = !A.


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


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

Почему?

∃a a <=> ꓶa чем не вариант? )) нет равенства, но эквивалентность-то есть!

Не, тут опять же нужно определиться: мы имеем дело с описанием логики, и или работаем с уже сформулированной?
∃a a <=> ꓶa чем не вариант? ))

Во-первых, это логика предикатов. Во-вторых — да, такое утверждение сформулировать можно, оно будет ложным. Но можно сформулировать много ложных утверждений, 2*2=5, например :)
Надо же, чтобы его можно было еще и вывести.

Ну так и я о том же. Ложным оно будет, если я не смогу принудительно сказать, что оно — аксиома. Введя таким образом парадокс в аксиоматику, и сломав логику к чертям! Что и сделали древние философы. )))
UFO just landed and posted this here
а почему а — «индивидуальная переменная», а не предикат? Потому, что с маленькой буквы? А <=> ꓶА — лучше?

Синтаксис — не моя сильная сторона, признаю. ;)

Напишите, как надо, если возможно.
UFO just landed and posted this here
Это бы проканало, если бы предикат не использовал в качестве объекта самое себя. Там же как "Это утверждение ложно" — вот именно это. Это как бы P(P). Поэтому ∃P P(P) <=> ꓶP(P). Я подумал, что тут уж (P) — лишнее… Не? ;)
UFO just landed and posted this here
Синтаксически неверно. a должно быть обёрнуто в предикат, нельзя к индивидным переменным применять логические связки.

Я так интерпретировал, что <=> и есть тут двуместный предикат. exists a: <=>(a, !a);

UFO just landed and posted this here
UFO just landed and posted this here
Может, выход за границы массива — одна из таких возможностей.
UFO just landed and posted this here
А 99.9% людей ничего не знает про машину Тьюринга.
Зато знает, что дорогу нужно переходить в специально отведенных местах.
Любой «недосмотр» программиста или программный сбой — это и есть «логический парадокс», который нарушает логику.

И как ошибка нарушает логику?
В программе же ясно написано — бесконечный цикл. Вот он бесконечно и выполняется.


А если «так было задумано» — есть предусмотренный выход из бесконечного цикла.

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

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

glutMainLoop();

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

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


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

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


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

Деление на ноль может вызывать разные спецэффнкты.
Если мне не изменяет склероз, то при целочисленном делении возникает прерывание у процессора.
Как прерывание обработать, такое будет и поведение.
При делении чисел с плавающей точкой может просто вернуться специальное значение — NaN.
Никаких особенных проблем.
Исключение при делении на ноль — результат сответствующей обработки прерывания.
Если исключение не обработать самому, будет выполняться обоаботка, прописанная в программу по умолчанию (из стандартной библиотеки, компилятором при генерации кода, или та, что прописана в интерпретаторе.
Причем скорее всего необработанное исключение деления на ноль вызовет старый добрый крах программы с соответствующим предупреждением или без него.
А в других случаях программа "грязно выругается" и продолжит работу.

Да не в количестве дело! А в дискретности.

Есть дискретная (цифровая) технология, есть аналоговая (непрерывная). Будет, наверное, квантовая — там свои плюшки.

Троичная она, или семеричная — это НЕ ВАЖНО. Если присутствует дискретность, то проще взять по минимуму (два состояния) — тогда вероятность «перепутать» сигналы наименьшая.

Аналоговые системы имеют свои преимущества, дискретные — свои.
Да не в количестве дело! А в дискретности.

Что-то смутно припоминается, что в троичной логике ЭВМ использовались состояния -1, 0 и 1. Причем есть адепты, до сих пор полагающие, что для ЭВМ это наилучший вариант.


то проще взять по минимуму (два состояния)

Производители SSD с вами не полностью согласны.

UFO just landed and posted this here
UFO just landed and posted this here
Ну тогда вот вам конкретный пример — «логическая ошибка» в виде неправильно соединенных проводов, приводи к «логическому парадоксу» — короткому замыканию.
Я думаю, что вы отучились абстрактно мыслить.
UFO just landed and posted this here
Устоявшуюся у кого? Именно абстрактность логики и является «устоявшимся термином», а вы его отрицаете.
UFO just landed and posted this here
Ну и что? Некоторые занимаются производством компиляторов и знают наизусть стандарты.
А некоторые занимаются казуистикой и подменой понятий.

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

К тем кто их прочитал еще тогда когда другие пешком под стол ходили.
И опять: что будет, если попытаться применить приведённое Вами определение логического парадокса (как логически корректного рассуждения, приводящего к противоречию) к описанному Вами случаю? Про «логическую ошибку» пока молчу (её тоже, по-хорошему, надо бы строго определить, раз уж на то пошло).
Абстрактное и конкретное — это взаимосвязанные и противоположные по смыслу понятия философского, научного и обыденного дискурсов, выражающие в своей взаимосвязи проявление единства между абстрактным и конкретным знанием.
gtmarket.ru/concepts/7161
То есть, ничего не получится, судя по тому, что Вы отказываетесь давать ответ, понятный кому-либо, кроме Вас самого.
Или вы задаете некорректные вопросы непонятные мне.
Постарайтесь внятнее излагать свои мысли.
Ещё раз. Вы в качестве примера логического парадокса приводите короткое замыкание. Я спрашиваю, какие два противоречащих друг другу вывода имеются в данном парадоксе? Этот вопрос вполне может не требовать рассуждений, если можно просто явно указать — вот такой первый вывод, вот такой второй, вот здесь они противоречат. В Ваших словах этого нет. Что здесь может быть непонятным — честно говоря, неясно, если, конечно, Вы понимаете данное Вами определение парадокса (но я исхожу из того, что всё же понимаете).
Значит я правильно ответил на ваш вопрос, но по некоторым причинам он явился для вас «белым шумом».
Есть абстрактные понятия «логическая ошибка» и «логический парадокс».
И есть конкретные случаи этих ошибок и парадоксов.
В «конкретных» терминах «ошибка» при соединении проводов приводит к возникновению «парадокса» — короткому замыканию.
Процитируйте в Ваших высказываниях два противоречащих вывода, раз «ответили». Если их нет — получается, что «конкретный случай» на самом деле «случаем» не является, так как не соответствует требованиям, наложенным «абстрактным понятием».
Я опять не понял вашего вопроса.
Абстрактное понятие «логического парадокса», по определению, содержит два противоречащих друг другу вывода. Если какое-то явление является конкретным случаем этого абстрактного понятия, значит, оно содержит внутри себя два каких-то (опять же, конкретных) противоречащих друг другу вывода. Вы утверждаете, что короткое замыкание — логический парадокс. Какие в данном конкретном случае будут эти выводы?
содержит два противоречащих друг другу вывода

Это неверно — вся проблема в ограниченности применения двоичной логики.
Парадоксы возникают за границей ее применения.
Совершенно так же как и выход за границы массива.
А можно было сразу сказать «закон исключённого третьего нам мешает развернуться» и не парить нам всем мозг? Правда, выход за границы массива тут по-прежнему никак не увязывается, но, по крайней мере, что-то бы прояснилось.
tertium non datur

Я его приводил, но вы не реагировали — я сделал вывод, что вы не знаете, что это такое.
==============
выход за границы массива тут по-прежнему никак не увязывается

Абстрактное понятие — «выход за границы применимости»
Конкретное — «выход за границы массива».
Да, прошу прощения, латинского названия не знал (тем более что в том контексте оно непонятно к чему относится). Итак, Вам нужна логика, которая допускает некоторые вещи, которые в двоичной логике считаются парадоксами, за счёт того, что некоторые пары противоположных утверждений оказываются одновременно ложными. Осталось понять, как вычислительные машины, основанные на такой логике, позволят устранить влияние человеческого фактора на программные баги.
Для продолжения нужно решить «задачу о двух паровозах».
Не.

Логические парадоксы в голове, в не в логике.

С логикой все в порядке! ;)
Иии?

Это все парадоксы формальной логики а не двоичной. Согласен с предыдущим оратором — двоичная логика отнюдь не парадоксальна. Внутри себя.
Вы либо отрицаете очевидное, либо не хотите понимать.
В настоящее время мы не используем никакую другую логику — только двоичную.
Различные названия не меняют сути — аристотелева, двоичная, математическая, формальная, логика доказательств и так далее.
Сравните — истина-ложь, true-false, 1-0.
А теперь вы сравните: x v ((y ^ z) -> t) и 1-0
У вас вообще какое образование?
UFO just landed and posted this here
Где то здесь я рассказывал про своего знакомого кандидата фмн, которых экономил на вызовах функций — его специальностью тоже была прикладная математика.
Тут на мой взгляд два вопроса — первый, математика не является наукой поскольку не дает знаний об окружающем Мире.
Она всего лишь ИНСТРУМЕНТ для науки.
Второй, математика отвечает на вопрос СКОЛЬКО, а знания мы получаем при ответе на вопрос ПОЧЕМУ ИМЕННО ТАК, а на него может дать ответ только философия.
UFO just landed and posted this here
Ну и что? Каждый думающий человек в той или иной мере философ.
UFO just landed and posted this here
UFO just landed and posted this here
А какие вам ближе — их много всяких разных.
UFO just landed and posted this here
UFO just landed and posted this here
У меня классическое советское высшее образование и не одно.
Какая область знания вас интересует конкретно?
Встречный вопрос: а на какие известные Вам области знания подразделяется логика? Мы же не можем выбирать из списка, который нам неизвестен.
Вообще то Логика разделяется на две категории
— Логика доказательств
— Логика поведения — поведенческая логика.
================
Ну и бесплатный бонус — за все время своего существования Наука не дала Человечеству НИ ОДНОГО фундаментального Знания только технологии.
Электричеством пользовался еще Архимед, а мы до сих пор не знаем, что это такое.
=============
Наука делится на Фундаментальную и Прикладную.
Все что мы имеем — это заслуга Прикладной Науки, технологии полученные по методу «научного тыка».
Всего две категории? Неужели обязательно требовалось написать столько слов вместо того, чтобы, как просили выше по ветке, порекомендовать литературу по обоим категориям? Мы же, в конце концов, без знания этой самой литературы (и без Вашей подсказки) не могли сами догадаться, какие «области знания» Вы имеете в виду.
порекомендовать литературу

Как вы себе это представляете?
Книг тысячи, если не десятки тысяч.
Во-первых, я из все просто физически не мог прочитать.
Во-вторых, то что нравится мне может не понравится другим
=============
Ну так и быть, вот только вчера мне попалась книга, которая мне понравилась — Кольман, Зих; Занимательная логика; «Наука», Москва, 1966.
Как вы себе это представляете?

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

Кольман, Зих; Занимательная логика; «Наука», Москва, 1966.

ping 0xd34df00d — надеюсь, это то, о чём Вы спрашивали)
Или оно уже устарело
Вы считаете, что таблица умножения может устареть?
ping 0xd34df00d — надеюсь, это то, о чём Вы спрашивали)

Это вообще что?
Это вообще что?

Прошу прощения, не вполне ясно выразился (фраза была обращена не к Вам, а к упомянутому хабраюзеру).
UFO just landed and posted this here
Буквально на днях попалась книжка, которая мне понравилась — Кольман, Зих; Занимательная логика; «Наука», Москва, 1966.

Это же научпоп, а не учебник.

Неправильно. Это задачник из задач разных групп логики. А во второй части дана краткая теория тоже по группам. Как раз то, что вы хотели.
Кстати аварийное отключение энергоснабжения в Нью-Йорке в 1977 году было вызвано возникновением в электросетях именно возникновением логического парадокса.
Я конечно могу понять увлечение некоторых ассемблером, но какой объем кода на ассемблере потребует следующий фрагмент:

template<typename G, typename… U>
static void SetParam(G&, U &&… );

template <typename G, typename… U>
void Figure::SetParam( G& g, U &&… u)
{
g = {std::forward(u)...};
}
В свое время у меня был хороший знакомый кандидат физико-математических наук и по совместительству программист. Вот только программировал он на машинах типа «Минск».
И там у них была проблема — каждый вызов функции требовал затрат машинного времени.
И сколько я не пытался его переубедить что под виндовс таких проблем нет, он так и продолжал экономить на вызовах.
Это просто один из примеров как ЯП накладывает отпечаток на способ мышления.

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

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

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

Именно поэтому я люблю С++ — могу делать все, что хочу.
А компилятор и без просьбы сделает если нужно.
UFO just landed and posted this here
В с++98 был для этого, но и тогда решал компилятор.
UFO just landed and posted this here
На счет стандарта не скажу, но Бьярн Страуструп именно так объяснял его значение — как рекомендацию для компилятора.
UFO just landed and posted this here
«Важно понимать, что в действительности использование модификатора inline является запросом, а не командой, по которой компилятор сгенерирует встраиваемый (inline-) код. Существуют различные ситуации, которые могут не позволить компиля¬тору удовлетворить наш запрос. Вот несколько примеров.
— Некоторые компиляторы не генерируют встраиваемый код, если соответст-вующая функция содержит цикл, конструкцию switch или инструкцию goto.
— Чаще всего встраиваемыми не могут быть рекурсивные функции.
В Как правило, встраивание “не проходит” для функций, которые содержат статические (static) переменные.»
(Герберт Шилдт, С++ базовый курс, глава 11, Встраиваемые функци)
UFO just landed and posted this here
А мне зачем стандарт? Я не создаю компиляторы.
UFO just landed and posted this here
Сейчас у меня 4 любимых ms c++6.5, clang 7.0.1, mvs 2017, mvs 2019 preview.
Предлагаю местному сообществу одну и ту же задачу, но в разных логиках.
— Парадокс «Буриданов осел».
— «Задача о двух паровозах».
================
Все что пытаются делать современные программисты типа «эвристики» или ИИ — это по-сути попытка обойти ущербность двоичной логики.
Но при этом никто не понимает, что создание ИИ на основе двоичной логики невозможно.
И все отказываются понимать, что ИИ по круче Скайнета уже давно существует — это Деньги.
Вот в связи с всем вышеизложенным, никто, случайно, не подскажет — нет ли какого способа такие дискусии нормально просматривать? Ибо то, что я имею счастье видеть на данным момент в хроме, оно явно не предназначено для постов, у которых есть больше чем один ответ…
Всегда можно нажать «показать ветку комментариев» (иконка со стулом) на последнем комментарии в ветке. Не идеально, но так хотя бы можно каждую цепочку отдельно проследить.
И наслаждатся одиноким столбиком отформатированным на 62 символа, уходящим в небеса…
Не, ну если у кого-то ностальгия за олдскульными мониторами, 80*60 символов, вот это вот все, то им-то норм. Или увлекающимся восточными писменами, которые сверху вниз все пишут — тоже, наверное, кавай и все такое.

А остальным что делать?..
Я что, должен думать, почему здесь System.Console, а там windows.h?

CPP — язык кроссплатформенный. В данном конкретном случае ты пишешь под платформу Windows. C# — язык моноплатфоменный. То есть System это и есть Windows в данном случае — нет необходимости указывать название платформы
Я правильно понимаю, что если вы обдумываете что-то, но при этом не знаете, какие именно нейроны и синапсы активированы, то мышление это- кривое и ненастоящее? Ремонт двигателя через трубу?

Articles