PureBasic 6.40

Сделаем математику на салфетке.

Возьмём такой пример кода:

cfg := &config{
  foobar: "hello",
  baz:    "world",
}

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

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

У меня на ноуте 42 проприетарных проекта Go, 3,578,818 строк. Среди них 9.5% - табличный код. (Посчитал скриптами: 1, 2)

(Здесь можно отклониться в сторону того, что время чтения ≠ объём кода. Среди всего времени чтения кода (а разработчик не читает весь код), сколько времени уделяется именно табличному коду? Я затрудняюсь говорить за других, но в моём случае - редко. Для меня чаще всего таблицы - это неинтересный наполнитель. Там, где таблица действительно выполняет важную роль, она перестаёт быть таблицей и обрастает нетабличными данными или комментариями. Пример: 3.)

Я в детстве на Laser Basic игры для zx spectrum'a писал :)

вкус вижу

???.. ;))

вкус вижу

Цвет слышу, звук чую. Синестезия называется :)

Цвет слышу, звук чую. Синестезия называется :)

Помню, помню времена, когда и я «звук показывал»... Музыку, точнее говоря: «цветомузыку», которая тогда была «в моде», на продажу «клепал». :)))

foobar: «hello»,

Надо чтобы этих данных было много и они были однотипные. Есть инструменты для выравнивания кода, пробелы вокруг операторов оставляют, пробел после запятой и т.д. Так вот сделал человек выравнивание комментариев и подобных строк foobar: "hello", так вот я даже такое возвращаю обратно, пришлось свой tidy писать, который этого не делает. Представим константы или переменные выровненные таким образом, ты копируешь имя переменной/константы, прыгаешь к её объявлению, чтобы посмотреть что там, и тебе вместо рядом стоящего значения надо смотреть в правую часть экрана, в правую часть IDE и так чтобы строкой не лохануться, да, окно какое нибудь подвести чтобы над верхней границей окна было понятно что это строка на одном уровне.

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

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

Я знаю по крайне мере один шрифт, нацеленный на программистов, но не являющийся моноширинным — Input Sans 1.

Реальный вопрос не в том, должны ли существовать моноширинные шрифты, а в том, окупается ли зависимый от выравнивания стиль текста. По моим наблюдениям 2 — нет.

если кому-то так удобно, то это личное дело каждого

Аналогично. Тот факт, что 99% разработчиков успешно используют моноширинные шрифты, неоспорим. Но является ли их выбор объективно наилучшим — другой вопрос.

моноширинным — Input Sans

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

используют моноширинные шрифты, неоспорим. Но является ли их выбор объективно наилучшим

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

Ого, это же ему уже лет 30, не меньше.

Если шрифт портит даже 10% кода - он плохой.

Если шрифт портит даже 10% кода - он плохой.

Но если 90% то ещё хуже

Конечно. А моноширинный портит 0%.

Представим константы или переменные выровненные таким образом, ты копируешь имя переменной/константы, прыгаешь к её объявлению, чтобы посмотреть что там, и тебе вместо рядом стоящего значения надо смотреть в правую часть экрана,

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

Конечно. А моноширинный портит 0%.

Мы видим слова как рисунок, не читая по слогам и если это не разряжённая фигура то его легче воспринять. Пример я вижу у людей папки квадраты 5x5 см и снизу название, спрашиваю, разве так удобно когда во первых сортировка слева направо, то есть тяжело найти папку начинающуюся с Q, потому что в верхнем ряду например P а в нижнем ряду уже R и надо подняться на 5 см вверх и искать первую букву слова начинающуюся с Q. В то время как в режиме «Список» со шрифтом имеющим малый межстрочный интервал скользишь вниз на одном уровне и гарантировано не пропустишь Q и в ряду у тебя 60 элементов, а на экране умещается 500 элементов, в то время как у чела с папками 5 см на экране умещается 5x10 папок, то есть 50.

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

а все остальные выровнять удобным способом

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

Вау бейсик)) Это необычно🤗

Но если ты привык к Arial и используешь его при чтении форумов, то на кой привыкать к двум шрифтам

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

Чтение форумов и написание кода – разные задачи. И даже на форумах делают специальные теги для кода, внутри которых текст оформляется моноширинным шрифтом. Зачем – догадайся сам.

Как учить 2 языка программирования если вторым пользоваться не будешь, просто выкинь своё время

А вот это просто смешно.

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

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

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

Ого

Ага :)

шг, мыло

для которых создавались бейсик и питон

Правда??..

Правда, а что не так?

Просто не знал таких подробностей, вот и спросил... :))

Программисты уже привыкли к свойствам моноширинных шрифтов и стали зависимыми от них. Но это чисто прагматический аспект…

Программисты стали «зависимы» от моноширинных шрифтов так же, как от IDE, LSP и прочих инструментов. Это просто означает, что инструмент — работает. Судя по тому, как стремительно меняется мода на программистские шрифты, поменять начертание — не особая проблема. А вот моноширинность, очевидно, важна.

к эргономике чтения.

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

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

Реальный вопрос не в том, должны ли существовать моноширинные шрифты

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

Но является ли их выбор объективно наилучшим

Бессмысленный вопрос. Вы еще «объективно наилучшую» цветовую схему поищите. Слишком много субъективных факторов.

???.. ;))

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

копируешь имя переменной/константы, прыгаешь к её объявлению

Наезжаешь на имя константы в тексте курсором, и LSP тебе показывает выпадайкой, что в ней…

BASIC изначально было аббревиатурой Beginner’s All-purpose Symbolic Instruction Code.

Beginner’s при этом можно трактовать по-разному. Лично я категорически против того, чтобы с бейсика начинать учить будущих программистов, и согласен со Столяровым, предлагающим для этого паскаль. А вот для непрограммистов, желающих вкатиться в любовный и сладкий мир написания программ для своих нужд – было самое то. (Сейчас, наверное, питон для того же получше будет.)

согласен со Столяровым, предлагающим для этого паскаль

Я знаю, что у него есть аргумент за Паскаль. А против Бейсика есть?

LSP нету в гитлабе, диффах и много где ещё. Текст — lingua franca, поэтому им нельзя пренебрегать, даже если есть обходные лазейки.

За Столярова не скажу, скажу за себя. В бейсике можно мусорить переменными, не задумываясь о цене и реализации. В паскале ты должен явно объявить переменную, указав её тип.

Для обучения (обучения будущих профессионалов – особенно) это крайне важно. Поэтому мода на обучение программистов с применением питона меня тоже крайне удручает, кстати.

Есть и другие аргументы, но там уже надо уточнять, про какой диалект бейсика речь. Конструкции для структурного программирования во все современные диалекты внедрили, унифицированы ли они между собой – не знаю (а это тоже немаловажно). В классическом BASIC этого и близко не было. Когда я на нём написал программу на 2000 строк с применением GOTO и GOSUB, я понял, что пора валить. Но у меня до бейсика была ещё пара ЯПов, очень специфичных.

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

Лично я категорически против того, чтобы с бейсика начинать учить будущих программистов

Аналогично. Мне он как-то сразу не «зашёл», и начинал я с Assembler и Forth для Intel 8080A ( и отечественных «аналогов» ;) ) - люблю всё держать под контролем, никогда не боялся брать ответственность за это на себя, ну и с «железом» - периферией - мне нужно было работать.

Позже, уже на PC и под DOS, «переехал» на FORTH F-PC от Tom Zimmer, с которым позже довелось пообщаться, когда у меня появился доступ в FIDO... Классная была система, я на ней пописа́л тогда... :))

Ну а когда понадобились базы данных (рыночек, да), а никакой литературы по теории и устройству баз данных в наших краях было не найти, «ушёл» на Clarion Professional Developer V2.1 (под DOS). Но это уже был не столько язык, сколько среда разработки...

А на VisualBasic, уже под Windows и в «нулевых», младший сын в его старших классах «изготовил» для уроков информатики Logo, который там «зашёл» лучше, чем то, что им официально поставлялось... Каждому своё, да... :))

Эх, ностальгия!.. :)))

и согласен со Столяровым, предлагающим для этого паскаль

Не, мне тоже как-то «не зашёл»...

Сейчас, наверное, питон для того же получше будет.

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

Сейчас, наверное, питон для того же получше будет.)

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

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

копируешь имя переменной/константы, прыгаешь к её объявлению

Наезжаешь на имя константы в тексте курсором, и LSP тебе показывает выпадайкой, что в ней…

PureBasic тоже там умеет, но при условии запущенной программы. А также значения переменных.

GOTO и GOSUB

Начинал с AutoIt3 и там в FAQ было сказано, что не рекомендуется писать код с GOTO, так что я сразу исключил это. На форуме PureBasic сказали, что не надо истерик, надо просто знать где это использовать.

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

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

Важность кнопок, как и моноширинности, вообще не очевидна.

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

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

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

данных, что человеку будет труднее осилить длинный текст, набранную современным моноширинным шрифтом, нет.

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

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

И даже если так, пользователю всё равно придётся платить определённую цену за разнообразие: в браузере один шрифт, в редакторе другой. Нужно время на адаптацию.

Переформулировали по ходу?

Я там говорил о том, что моноширинные шрифты обратно-совместимы. Мой акцент был на табличном выравнивании: не будет его — пропадет острая необходимость в моноширинности.

Но я по-прежнему против моноширинных шрифтов (точно против большинства).

Вы еще «объективно наилучшую» цветовую схему поищите. Слишком много субъективных факторов.

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

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

Важность кнопок, как и моноширинности, вообще не очевидна

Сильно зависит от контекста (я про кнопки, а не про шрифты).

Лично для меня с «отказом» одной из двух моих рук кнопочный телефон остался единственным «рабочим"для меня вариантом. Так что для меня „важность кнопок“ вполне очевидна и бесспорна...

А вот смартфон - наоборот, „отвалился“ и лежит уже почти два года невостребованным...

если не поддерживает ооп, то как поддерживает qt?

если не поддерживает ооп, то как поддерживает qt?

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

Текущая версия имеет повышенную скорость работы со строками.

Денис, ты ли это?

После этого только про нескучные обои уместно писать :)

Лично для меня с «отказом» одной из двух моих рук кнопочный телефон остался единственным «рабочим"для меня вариантом. Так что для меня „важность кнопок“ вполне очевидна и бесспорна…

Что-то я пропустил драму, кажется.

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

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

Что-то в голос)) ТС не сдаётся, борется против обстоятельств и даже шрифтов.

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

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

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

Что-то в голос)) ТС не сдаётся, борется против обстоятельств и даже шрифтов.

Не, ну есть убеждения у человека, чего ж в этом плохого-то. А что не порвался до сих пор → это прям достойно уважения :)

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

Для обучения (обучения будущих профессионалов – особенно) это крайне важно. Поэтому мода на обучение программистов с применением питона меня тоже крайне удручает, кстати.

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

Я знаю, что у него есть аргумент за Паскаль. А против Бейсика есть?

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

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

Ядрёна кочерыжка… Ну давай, прочитай бегло портянку кода, представленного не моноширинным шрифтом. Там же вся «разметка» потеряется.

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

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

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

Круто!а вот FreeBASIC компилятор написан на самом FreeBASIC

постоянно насовывают в панамку

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