All streams
Search
Write a publication
Pull to refresh
-18
0
Send message
но, к сожалению, на данный момент чисто графических инструкций очень мало. Видел — у Google и некоторых других была инструкция для онлайн-продукта в стиле — весь экран затемняется и только нужная часть подсвечена. И выполняется в песочнице. Но все равно текст не всегда воспринимается, типа — что происходит? т.к. иногда встречались даже на китайском, язык поменять можно только если закончить инструкцию, но повторно инструкция уже не запустится. Глюки с локалью или с тем приложением (игра на андроид от китайских разработчиков)
Я думал, в первую очередь, о животных, когда писал этот комментарий.
Но сейчас обнаружил и вариант получше:
ИИ! Точнее, пиктограммы/знаки для общения с ИИ.

Про собак — их вполне обучали даже вождению, например
У ИИ с этим некоторые сложности

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

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

II) А я склонен, что это не просто параллельные, а одновременные. Т.е. грубо — 50% произошло от первого вида, 50% от другого. А у другого народа другие пропорции в пределах от (0%; 100%) до (100%; 0%). Мало того, в этих пропорциях могут быть поправки, например — третий вид, суррогатный. Когда и произношение, и письмо — заимствованное от более высокоразвитых цивилизаций, например — белые в Африке.

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

6) а я думал, что был иероглиф (который ближе к картинке), потом его расчленили на составные части, которые стали более универсальными, потом слишком сложные части еще раз порезали. И более простые элементы стали письменностью, как та же слоговая азбука в японском (хирагана и катакана). Я не утверждаю, что так появилось 100% букв. Мне для подтверждения хватит 1% от общего алфавита, причем для какого-нибудь одного языка. Тогда автоматически получается признание, что система работает и такое возможно. А дальше лишь установить точную границу в том, сколько именно букв получилось от иероглифов и когда-либо имели самостоятельно значение.

Эх, я сразу же выиграл. «Я» и сейчас имеет самостоятельное значение, а это более, чем 1%. Даже для пиктограмм свойственно утрачивать собственное значение, в зависимости от контекста и модификаторов, например — черта сверху может обозначать инверсию, т.е. было значение «красный», стало «не красный».
2 десятилетия спустя все точно также в какой-нибудь глубинке. Учил самостоятельно TurboPascal в школе (ничего другого подоступнее не было), чтобы в универе учить TASM. Хотел как-то научиться управляться с компьютером, но воз и нынче там. Причем под управлением подразумеваю не тыкать мышкой/клавиатурой в соцсети (тогда их не было), а контроль на уровне — какой код можно выполнять, а какой нет. Смотреть в любой момент память или состояние регистров процессора, выполняемые задачи и т.д. И при этом понимать что вообще происходит! До такого состояния как до Луны. Хотя нет, до Луны ближе.
Проблема подобных ошибок — непонимание логики работы, особенно в нетипичных ситуациях. Работа в нетипичных ситуациях вообще приводила к падениям ракет, когда новая ракета падала из-за старого кода. «Ariane 5». Хотя ошибки аэропорта Хитроу куда жестче.

Системы нынче стали настолько сложные, что даже болванка (заготовка) игры на новомодном движке может весить 200 МБ! Проблема в том, что человечество до этого момента не сталкивалось ни с чем подобным. До этого приходилось управлять максимум небольшими командами либо огромными однотипными системами. Или вообще пускать все на самотек и придерживаться традиций. А цена ошибки не была большой, т.к. часть людей вполне официально можно было считать даже рабами, как в той же Америке до 1865г.
Проходит 150 лет (+3) и системы усложнились на порядки. Ладно бы просто найти решение, но что делать с Legacy/наследием? Раньше решалось проще — повоевали и все, строй заново, без Legacy.

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

Может, стоит подумать в направлении такого созидательства? Посмотреть, что уже существует и делать свое, развивать. Типа «общество сложных систем», который позже станет институтом/университетом. На самом деле не взлетит, т.к. нужны будут финансы. Требовать финансирования глупо — можно перейти в режим грантоедов. Поэтому нужно подумать и в сторону о пользе, которую можно получить уже сейчас, пускай и другим путем.
там скорее не в переписывании как таковом, а в наследии. Существуют системы, в которых уже залиты ядра линукса. И им обновления уже никогда не прилетят. Например, какой-нибудь медицинский прибор. Но вот поддерживать такой аппарат — вполне нужны те, кто будут ориентироваться в ядре линукса, чтобы избавить уж совсем критические ошибки, которые могут повлиять на пациентов. А утечка данных иной раз с таких аппаратов не опасна, т.к. физически невозможна — аппарат может банально не включен в интернет-сеть за ненадобностью.
Весь сыр-бор в первую очередь из-за утечек данных, а часть индустрии на это клала. Образование (те же школы), медицина (кроме данных пациентов), многие бюрократические организации (особенно на просторах СНГ). Еще есть те, у которых компьютеры к сети просто не подключены.
И сразу ошибки, которые можно выявить на этапе тестирования.
1) Про вред курения. Если сравнивать курение человека, который живет на природе в чистой среде и питается исключительно чистыми продуктами (иных нет), живя далеко в Сибири, в Африке и т.д. с человеком, который ни разу не курил в жизни, но живет через дорогу от металлургического комбината, хим.завода или даже все вместе. Про всякие тепловые электростанции молчу. То я бы не сказал, что курение вредно, оно даже может быть полезно, вроде прививок, при количестве 1-2 сигареты в месяц или год. Особенно, если человек из природной среды поедет к человеку города или живущему рядом с промышленностью. так сказать — заблаговременная подготовка к нахождению в опасных условиях.
Был даже забавный случай, когда некоторых знакомых пытались убедить бросить курить, аргументируя вредом здоровью. Особенно смешно звучало для металлургов и сварщиков, особенно для сварщика, который варит без какой либо защиты для органов дыхания. Покупка защиты отложена до лучших времен, а сейчас банально з/п не хватит, ныне платят за такой труд всего лишь около 6 тыс руб (инфа 2-х летней давности по з/п, но я не слышал о кардинальных подъемах з/п).

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

Отсюда — приходим к известному «все лекарство и все яд. Зависит от дозы». Слишком много с/с++ стало ядом, причем на подобии медленно действующего токсического яда. В небольших дозах незаметен, а позже ошибки накапливаются и могут вызвать смерть пациента (тут ссылку про разорение кого-либо из-за ошибки программиста)
Которая ближе к блок-схемам и не имеет транслятора в машинное представление. Ранее (в прошлом веке) транслировался ручками инженеров, а сейчас пытаются придумать транслятор через си/паскаль/другие. Тут ситуация как с UML. И UML, и ДРАКОН не являются языками программирования (у них для этого не определены ключевые слова), но можно выполнить генерацию кода по схеме, в отличии от блок-схем.
Мало того — у ДРАКОН даже с типами более, чем никак, вообще никак. Поэтому типы берутся от языка-посредника, от которого берутся и ключевые слова.
Также у ДРАКОНа пока все плохо с процедурами и функциями. Нет, не с реализацией, а с логикой. Создается косвенная логическая связь, которая усложняет программу. Хотя ситуация типичная для всех языков программирования, но намного лучше неявных вызовов, т.к. есть хотя бы упоминания. При вызове процедуры вы по умолчанию считаете, что она работоспособна и без ошибок.
Еще у ДРАКОНа все плохо с ООП. Т.е. методы объекта описать еще можно, а вот объекты, их наследования и прочее — уже нет.

Было бы интересно увидеть сравнение на уровне ключевых слов/действий.

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

Я расцениваю ДРАКОН именно как свод полезных правил, парадигма против спагетти. А его ругают как будто он самостоятельный язык. Почему ООП не ругают? У него вообще нет своего языка, все время какие-то посторонние языки его используют. Все потому, что ООП — не язык, а парадигма!

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

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

Во-первых — не любого! Как минимум — не совпадающего с фоном, а желательно вообще контрастным
Во-вторых — позволяет абстрагироваться с потерей информации. Т.е. при описании фото растения вы можете пропустить информацию о том, что это растение болеет (нейросети уже учатся). Также вы не можете описать то, чего не знаете. Например, некоторые не знают что такое штангенциркуль, соответственно — не смогут его опознать.
В-третьих — занимает больше места. Одна иконка размером с 2-3 буквы заменит словосочетание «красное яблоко» (13 букв+спецсимвол пробела)
Еще пример — как мужчина попытайтесь описать название нескольких розовых помад разных оттенков и покажите это описание женщине. Тут большинство мужчин будет бессильно описать разницу между помадами, даже если вы ее заметите. Бессилие растет с ростом количества помад, для 2-3-х единиц могут и кое-как справится.
человек сможет выбрать иглу для пункции из груды скальпелей, зажимов и тампонов даже если никогда не знал о ее существовании.

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

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

«собаки понимают язык глухонемых» — это сильное заявление…

Собаки поддаются дрессировке и способны понять 1-2 жеста и больше. Даже десяток вполне смогут. Или вы отрицали, что собаки могут понять до десятка жестов?
Я не говорил про всю полноту языка, тут даже люди не способны знать всю полноту родного языка, особенно всякой терминологии, названия инструментов и явлений и редко используемых слов. Максимум — художественную полноту осознают. А перечислить по памяти названия врачебных инструментов (кроме врачей и причастных)? Вряд ли рядовой обыватель справится. Я молчу про диалекты и местные наречия, когда одному и тому же явлению находятся разные слова.
Про ромбик — не согласен. Этому учатся. Да и еще возле самого ромбика проставляют ±, т.е. куда идем в зависимости от того, ложное или истинное условие. И только потом, спустя время, придет автоматизм, а потом и понимание:
«если так, то делаем это, а если иначе — то делаем то»


Учил только ASM (на базе TASM!), макросы и компиляцию в рамках университетского курса и самостоятельно для собственного интереса. ASM для х86. Позже FASM, но на уровне хобби.
Для Itanium не было визуального ассемблера, но архитектура приказала долго жить. Значит, не в визуальном ассемблере дело.
А кто пользуется обычным ассемблером? При написании веб-сайтов, веб-сервисов, игр, бизнес-приложений и т.д. И тут видно, что для сложных систем нужны слои абстракции, макросы и куча готовых компонентов с автоматизацией, чтобы не описывать «пересылку каждого байта».
неспособные к нормальной записи нормальных слов

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

«принцип Шоу»: «Создайте систему, которой сможет пользоваться дурак, и только дурак захочет ею пользоваться»

андроид, iOS изначально настроены дружелюбно, а еще MS-DOS(в виде первых Windows) и Linux получили графический интерфейс, дружелюбный пользователю. Вопрос — это считается за «систему, которой сможет пользоваться дурак»?
Я в курсе, что ныне Windows далеко ушла от MS-DOS и строится во многом на других принципах, хотя многие базовые понятия пока остались, типа — управление мышью и клавиатурой (сенсорный экран и жесты пока не всеохватывающие), хранение на жестком диске (а не в оперативной памяти — энергонезависимая память только-только появляется), 2D монитор, а не голографический или нейроинтерфейсный и т.д.

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

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

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

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

А как сами понимаете эти понятия?
1. различие достигнуто по причине, о которой я уже упоминал — скорость письма. А также из-за звукопроизношения и необходимости делить на более простые формы-атомы.
Проще это демонстрировать на диаграмме Венна, когда по вложенности идут следующие множества:
Изображения/фото->рисунки->пиктограммы->иероглифы->базовые элементы->буквы->буквенные модификаторы (точки над ё).
Да, по мере вложенности часть информации теряется. И это больше похоже на слои абстракции, т.к. более вложенное множество не может продемонстрировать все достижения предыдущего слоя. Но получаем универсальность.
Картину зимнего леса не получится использовать для объяснения принципа работы компьютера. Но зато картина зимнего леса может эффективно заменить текст описания этого зимнего леса.
Имеет три параметра — скорость письма, универсальность применения, сложность обучения, сложность написания и информативность. Человечество ориентировалось на первые четыре в ущерб информативности, поэтому и дошли до букв. Тот же значок банана трудно нарисовать черным цветом, отсюда упрощение и сложность обучения иероглифу.

2.1) «Гулливер» Джонатана Свифта. Описание общения с помощью предметов. Они не знали про пиктограммы, поэтому таскали с собой целые мешки. А так достаточно одной книги со всеми возможными заменами слов в виде пиктограмм и просто тыкать на нужной странице.
2.2) Сейчас некоторые диалоги можно строить с помощью пиктограмм, этим даже пользуются. Например — когда пишут про 18+, используя (отпечаток помады от женских губ), (банан), (клубника) и т.д. IT специалисты пока вынуждены ждать, т.к. пиктограмм Shift, Ctrl, Tab и прочего еще не завезли. Названия клавиш не сильно интересны, а вот всякие faceboot, google и прочие значки могут пригодится.
2.3) Язык глухонемых. Извините, зашел с козыря. Мало того, язык глухонемых можно использовать для общения с теми существами, у которых человекопонятная речь в принципе невозможна из-за принципиально другого строения, например — собаки, обезьяны и прочие. Просто вместо жестов применять картинки.

3,4) некоторые иероглифы/пиктограммы могут не иметь самостоятельного значения или оно бессмысленно отдельно. Даже для слов встречается — есть слово «ненавидеть», но нет слова «навидеть». В остальном — повторение п.1.

5) Смысл букве именно сейчас обрести отдельный смысл?
6) Вы отрицаете, что буквы при ныне отсутствующем самостоятельном смысле когда-либо ранее имели отдельный смысл?
Я соглашусь про Овно-кодинг.
Но ваш комментарий практически типичен (убрал одно слово):
в связи с низким порогом вхождения овнокодить на ______ языке будет больше овнокодеров. Хорошо, если таковые вовремя остановятся, и не полезут овнокодить ответсвенные системы.

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

Я чуть выше уже писал — мы уже пишем на визуальных языках, но видя текст, думаем, что это текст, набор строк. На самом деле уже давно нет и даже от иных авторов требуем добавить визуальные стили тегами Code lang=«язык программирования», чтобы удобнее читать, а это именно визуализация. Просто мы недалеки от того, что в том же ассемблере инструкцию MOV (переместить данные) можно заменить на обычную стрелочку, типа
Ячейка1 U--> Ячейка2 // да, я помню, что ранее нельзя было из оперативы в оперативу перемещать, только через регистр проца, как сейчас — не знаю. Вряд ли разрешили на х86. Поэтому просто немного пошалю
Ячейка2 += 115 // Вместо инструкции ADD, добавить
Ячейка2 =? Ячейка3 // вместо инструкции CMP, сравнить
(>0?)===> Goto1 // вместо JPM с условием (JMP с условиями забыл, поэтому тут для примера больше нуля)
Развить тему и мы получим действительно визуальный ассемблер с низким порогом вхождения. А вот как избавиться от кодинга Овнов — это сложнее, но реализуемо современными средствами. Точнее, если разработать на базе имеющихся средств. Правда, бюджет потребуется серьезный, а как привлечь деньги на подобные разработки я не знаю, где есть обязательное применение страхующих методов (для случаев невозрата инвестиций).

Продолжаю про ассемблер. По сути — мы пишем на макроязыках для ассемблера с расширенной поддержкой и некоторые компиляторы языка не переводит в машинные коды, а является трансляторами из «новомодного языка» в Си, из Си в какую-нибудь абстракцию машинных кодов или ассемблер, а оттуда уже происходит компиляция в… Машинные кода? Нет, в код, допустимой ОС и часть процедур внешние и ОС сама их предоставляет и выполняет, хотя часть полученного кода — вполне машинные инструкции. Различные программы на чисто машинных инструкциях ближе к эпохе DOS, а не современной с 101 изоляцией.
Буква современного алфавита, причем только для некоторых языков, не обладает свойствами пиктограммы. История развития многих языков на это намекает, те же «Азъ Буки Веде Глаголь...» и последующее сокращение лишних или неполиткорректных сущностей до современного уровня или заимствования от других народов. Возможны позднего придумывания, например, «ё».
Также во многих языках существуют ситуации, когда буква может обозначать целое слово. Аббревиатуры
Не забываем, что многие народы «перескакивали» целые эпохи развития и могли получить свою письменность относительно недавно, особенно это касается малых народов, не являющимися на момент получения письменности государствообразующим.
И еще было упущено иероглифическое написание, когда даже сейчас можно каждой букве подставить свою пиктограмму-иероглиф, что даже так и делается — азбука для детей или шифрованные сообщения (простая замена написания), но особо не распространено среди остальных, т.к. является усложнением написания и влияет на скорость письма. Скорость письма отходит на второй план только при появлении доступного аудио- или иного фиксирующего оборудования, но до этого всю историю развития человечества именно скорость письма была критична, особенно до широкого распространения книгопечатания.
Соответственно, в будущем вполне возможен переход на иероглифичные стили письма. На это намекает широкое распространение эмоджи/смайликов, которые даже стало удобно набирать в различных мессенджерах/общалках/смс с поддержкой на уровне ОС (андроид и прочие). Но этому явлению в сверхшироком массовом сегменте буквально два десятилетия — первое десятилетие у каждого свои иероглифы-смайлики, второе — смайлики уже на уровне целых экосистем и операционных систем. Почему выделил только последние два десятилетия? До этого телефоны и компьютеры, как и интернет, не были доступны широкому кругу пользователей, в т.ч. домохозяйкам, обычным работникам, студентам, школьникам и другим не IT-специалистам, которым хочется писать в чате да котиков рассматривать, а не «изучать новое, неопознанное и очень сложное» без онлайн-сервисов, без связи с другими ПК, высокая стоимость этих самых ПК, никакая функциональность телефонов (максимум — телефонная книга в крошечном экране, и то не всегда). И т.д.
Я не видел аргументов, чтобы JMP-инструкции ассемблера (или goto-инструкции ЯП высокого уровня) можно было легко читать. Даже есть название для этого — спагетти-код. Мало того — даже отказ от JMP/GOTO инструкций не исключает появления плохо читаемого кода, который достигается методом «все вместе» без разбиения на процедуры, функции и т.д. А еще есть неявные вызовы, которые расцвели у скриптовых ООП-языков.

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

И видя, что и в тексте можно поломать и отстрелять себе ноги и все на свете, мы продолжаем ругать визуальные языки. Причем обучение не гарантирует получение знаний, которые позволят писать хороший и качественный код. Это не из-за «самоучителей для чайников», а просто потому, что чем сложнее создаваемая система, тем меньше людей, достигший того же уровня, соответственно — меньшему количеству людей потребуется решение. А сами решения могут быть сопоставимы по сложности с другими сложными системами, разве только на порядок проще, но все равно остаются на несколько порядков сложнее задач из самоучителей.
Всегда мечтал о чем-то подобном в современном мире. Но современном, допустимо не старше 15 лет. Начинал учиться на DOS-программах (на WinXP в эпоху без мобильного и местами без любого интернета) — TurboPascal была первой. Немного ностальгии.
Современные экраны 1280х1024, 1366х768 и больше, на них можно отобразить больше информации, причем часть информации задать графически (что невозможно в текстовом режиме), часть информации открывать динамически — вкладки, спойлеры и другие способы узнать подробности.
Жаль, что многие современные отладчики недалеко ушли от DOS-времен, это при условии если отладчик вообще запустится. Встречались даже отладчики для ЯП высокого уровня, которые предлагают отладку только для ассемблерного кода, т.е. логическую ошибку в них найти без знания ассемблера иной раз невозможно.
В названии же!

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

В одной мобильной игре было задание: «Напечатайте Название игры». Правильный ответ: «Название игры» (т.е. не надо было вспоминать, как называется игра, а просто набрать текст ответа посимвольно, который в кавычках, регистр неважен)
Во многом согласен. Хотя обычные языки программирования любят не используя горизонтальное пространство максимально использовать вертикальное. Это приводит к распечаткам кода, когда весь код в один столбик и не используется большая часть листа. Ну хотя бы в 2 столбца! Особенно для всяких IF актуально — на уровне логики там действительно 2 столбца. Первый — для true, второй — для false ветки. Мало того — даже обозваны ветками, что подразумевает дерево, но в тексте стоят последовательно.
Читал книжки в меру и давно лишь с целью почерпнуть интересные идеи, которые можно применять сегодня или даже в качестве извращений аналогично Brainfuck. Си языки с их не всегда логичной работой (i++ + i++ и прочие) тоже являются своеобразным Brainfuck. Я молчу про регулярные выражения, которые больше инопланетный язык.
Спасибо за наводку. На хабре была такая статья: Моноширинные шрифты с программистскими лигатурами
Но я подразумевал не только символы <=, >=, !=, := и прочие, но и ключевые слова false, true, if then else, for и т.д. А также символы, определяемые пользователем или библиотекой — названия функций, переменных и т.д.

И тогда да, действительно будет близко даже к 1.85D, останется добавить Drag&drop панельки для готовых наборов. Еще пару деталей — и 2D, практически визуальный язык, который получили эволюционным путем, сохранив всю мощь по пути

Information

Rating
Does not participate
Registered
Activity