The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Crystal 1.5, opennews (??), 25-Июл-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


89. "Выпуск языка программирования Crystal 1.5"  –1 +/–
Сообщение от Тот_Самый_Анонимус (?), 25-Июл-22, 22:28 
>У вас синдром утёнка, уважаемый.

Когда выучил модное выражение, то потрудись ещё его правильно применять. Синдром утёнка ту не причём. Границы блоков должны обозначаться знаками, а не словами, ибо когда операторная скобка выглядит как оператор, то это бред. Такойже бред, как логические функции записывать словами. А если не бред, то тогда надо быть последовательным до конца и записывать арифметические операции словами: plus, minus итд.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

145. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 26-Июл-22, 13:44 
>А если не бред, то тогда надо быть последовательным до конца и записывать арифметические операции словами: plus, minus итд.

add(a, b) - норм ведь

Ответить | Правка | Наверх | Cообщить модератору

161. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 26-Июл-22, 18:10 
> add(a, b) - норм ведь

Но a+b короче разика так в ТРИ... :)

Ответить | Правка | Наверх | Cообщить модератору

168. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 26-Июл-22, 19:50 
> Но a+b короче разика так в ТРИ... :)

ну эта же "коротизна" она на уровне формального языка, не машинной инструкции, где как не крути есть допустимый минимум кодирования той или иной операции. a+b или add(a,b) одинаково будет представленно (закодировано) в виде КОП (код операции) в зависимости от архитектуры. Отсюда не вижу принципиальной разницы "коротизны" для формального языка. Да мы экономим размер исходного кода, но не машинного. А "коротизна" машинного кода, думаю важнее. Я вообще не сторонник всех этих формальных языков, допускаю только один формальный язык, мнемонический язык машины. Такой язык лучше с точки зрения понимания машины (архитектуры), ибо зная как работает машина, можно оптимально писать под нее программы.

Ответить | Правка | Наверх | Cообщить модератору

172. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (171), 26-Июл-22, 23:13 
Оптимизировать надо под людей, поддерживающих системы. Машина железная, пережуёт.
Ответить | Правка | Наверх | Cообщить модератору

176. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 27-Июл-22, 00:17 
> Оптимизировать надо под людей, поддерживающих системы.

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

> Машина железная, пережуёт.

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

Правильный ход мыслей?

Ответить | Правка | Наверх | Cообщить модератору

186. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Анончик (?), 27-Июл-22, 10:25 
Автомеханикам не место в ИТ.
Ответить | Правка | Наверх | Cообщить модератору

238. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 29-Июл-22, 01:32 
> Автомеханикам не место в ИТ.

айтишники не должны создавать автопилот для машин они же не механики :)

Ответить | Правка | Наверх | Cообщить модератору

245. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 29-Июл-22, 22:14 
> айтишники не должны создавать автопилот для машин они же не механики :)

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

Ответить | Правка | Наверх | Cообщить модератору

246. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 29-Июл-22, 22:20 
> А чего такого механического в автопилоте, уж пардон?

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


Ответить | Правка | Наверх | Cообщить модератору

249. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (249), 30-Июл-22, 00:58 
> ага смузихлеб будет программировать бортовую систему не зная механики машины.

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

Там тоже разделение труда. И на абстрактном уровне что в fly by wire что в авто по шине полетит условное "мотор дай 50", как оно там это унутрях обеспечивает интересно только его локальному ECU, или как оно там у кого компьютер при движке называется, где-то там унутрях его собственной фирмвари, с чем вообще совсем другие кодеры разбирались, не имевшие никакого отношения к автопилоту.

Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 27-Июл-22, 16:53 
> Оптимизировать надо под людей, поддерживающих системы. Машина железная, пережуёт.

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

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

195. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 27-Июл-22, 16:49 
> ну эта же "коротизна" она на уровне формального языка, не машинной инструкции,

Угу, она на уровне инструкций к моим пальцам. Которые совсем не рады этому.

> где как не крути есть допустимый минимум кодирования той или иной
> операции. a+b или add(a,b) одинаково будет представленно (закодировано) в виде КОП
> (код операции) в зависимости от архитектуры.

Зато моим пальцам сильно предпочтительнее первый вариант. По тем же причинам {} лучше чем begin/end.

> Отсюда не вижу принципиальной разницы "коротизны" для формального языка.

Зато видят мои пальцы, на которые нагрузка утроилась. RSI никогда не ощущали? :)

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

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

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

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

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

204. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 27-Июл-22, 21:51 
> Угу, она на уровне инструкций к моим пальцам. Которые совсем не рады
> этому.

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

> Зато видят мои пальцы, на которые нагрузка утроилась. RSI никогда не ощущали?
> :)

автокомплит, в помощь

> Как бы это сказать? У ассемблера есть одна маленькая проблемка: он вообще
> паршиво поддается структурированию.

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

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

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

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

в этом то и проблема, держать все в одной голове.

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

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


Ответить | Правка | Наверх | Cообщить модератору

227. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (227), 28-Июл-22, 20:48 
> жаль, что машины так не могут, а то переваривают всякий гамнокод.

Да почему? Тормозят и глючат просто изумительно. Особенно если гамнокодом накормить.

> автокомплит, в помощь

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

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

В ассемблере нет штатных средств декларирования намерений, нормальной типизации, средств организации структур данных и проч. Проблема в том что
1) Это не наглядно и нет хорошей декларации структуры которая у меня в мозгу.
2) Остальные не телепаты чтобы все это знать.
3) На большом проекте я и сам full view не удержу в голове, да и не надо это, только "общую картину" и "что активно кодится сейчас". Не следование данному паттерну сильно нагибает максимальный размер и уровень сложности проекта который реально своротить. А иногда хочется и вещи посложнее хелловорлдов делать.
4) Никакой верификации что фактические действия совпадают с намерениями - нет. Это ведет к багам на манер яваскриптеров, когда можно в принципе замесить бананы, гвозди, яблоки и что-то еще, сразу может даже и не упадет, а откуда оно потом вон тот бред через полчаса счета берет - поди догадайся вообще. Все тулсы для формальной верификации в жестком пролете.

> Что асм запрещает раскидать куски кода по разным файлам, потом их инклюдить?

1) Это не описывает допустим прототип функции и что я его правильно вызываю.
2) Это не описывает истинный характер данных.
3) И кстати это все не портабельно а писать код каждый раз с ноля под разные процы мне таки лениво.
4) И кстати на том же сишке вполне реально затестить сишный алго на компе, с мощной инструментацией, типа ubsan/asan/etc под fuzzer'ом, и 1 в 1 его на МК какой перетащить потом, будучи более-менее уверенным в этом блоке кода, что он способен пережить взаимодействие с враждебным внешним миром, получая оттуда любую мыслимую труху.

> а чем код ядра линукса лучше?

Я в нем достаточно нормально навигирую. А благодаря требованием Торвальца "чтоб лезло на экран" я с снайперской точностью гашу баги штуками типа git bisect'а. Я могу даже вообще не знать этот код и подсистему, но при этом за весьма обозримое время локализовать проблему, всех причастных к ее созданию, а в половине случаев даже и экстренный патч себе скроить, просто посмотрев как оно было, что поменяли и прикинув почему это отъехало.

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

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

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

> в этом то и проблема, держать все в одной голове.

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

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

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

// NB я умею прогать на штуках 5 разных асмах, правда x86 знаю весьма базово, ибо мерзость

Ответить | Правка | Наверх | Cообщить модератору

237. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 29-Июл-22, 01:30 
> Да почему? Тормозят и глючат просто изумительно. Особенно если гамнокодом накормить.

ответ на этот вопрос дает замечательный мультик, https://www.youtube.com/watch?v=vIZVWVJ4_9M

Эйййй, двое из ларца .... :))))))))) загибайте

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

типы, структуры это же формальные понятия, а машина работает с понятием плоской последовательностью. Что значить создать массив из N элементов с точки зрения асм или любую другую структуру? Что из себя представляет тот же C++-ный код в асм листинге? Что мешает писать на асм так же как и генерит компилятор? Компилятор лучше сделает? - не согласен.

> Проблема в том что
> 1) Это не наглядно и нет хорошей декларации структуры которая у меня
> в мозгу.

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

> 2) Остальные не телепаты чтобы все это знать.

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

> 3) А иногда хочется и
> вещи посложнее хелловорлдов делать.

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

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

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

> 1) Это не описывает допустим прототип функции и что я его правильно
> вызываю.

прототипы, соглашение об вызовах все это формальные понятия.

> 2) Это не описывает истинный характер данных.

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

> 3) И кстати это все не портабельно а писать код каждый раз
> с ноля под разные процы мне таки лениво.

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

> 4) И кстати на том же сишке вполне реально затестить сишный алго
> на компе, с мощной инструментацией, типа ubsan/asan/etc под fuzzer'ом, и 1
> в 1 его на МК какой перетащить потом, будучи более-менее уверенным
> в этом блоке кода, что он способен пережить взаимодействие с враждебным
> внешним миром, получая оттуда любую мыслимую труху.

баловался с МК на сях и ручками выставлял биты в регистрах, спрашивается зачем мне С, если тоже самое я делаю на асм?

> Я могу даже вообще не знать этот код и подсистему,
> но при этом за весьма обозримое время локализовать проблему

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

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

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

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

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

> А уж сделать на нем что-то типа хотя-бы сишного struct вообще не особо
> вариант.

а что представляет из себя struct в плоской памяти?

> Я про структурированность программы и данных с которыми она работает. В ассемблере
> для этого практически нет средств.

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

> // NB я умею прогать на штуках 5 разных асмах, правда x86
> знаю весьма базово, ибо мерзость

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

Ответить | Правка | Наверх | Cообщить модератору

247. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 30-Июл-22, 00:29 
> Эйййй, двое из ларца .... :))))))))) загибайте

Если их заапгрейдить как следует - нормальненько получается.

> типы, структуры это же формальные понятия,

И это хорошо. Помогает мне помнить что я имел в виду, чем оперирую, помогает другим въехать в код. А еще декларация намерений в том числе и машине (компилеру, анализаторам, ...). Чтобы очевидные грубые несоответствия - отловить на этапе компиляции, а не когда программа сделает волшебный хренакс и (в случае управляюшей фирмвари) что-то $%нет, спасибо если никого не убив. Не хочешь на самолете полетать где fly by wire по твоим принципам сделан?

> а машина работает с понятием плоской последовательностью.

Вот прям все? B-деревья в "ненужно" запишем? Такой ли плоский uint32_t points[10][20][30]? Можно и N-мерный.

Более того. Даже С сделает корректный код для итерирования через массив struct'ов по индексу. Ну вот смотри, есть условное меню. Может на дисплее, консольке, еще где, в принципе не важно. Меню состоит из нескольких пунктов. Может быть какой-то хоткей для быстрого вызова конкретного пункта, ну и функция вызываемая когда пункт активирован. При помощи struct и макросни даже на сишке легко сделать (массив struct-ов) заполняемый типа
ITEM('l', "Go Left", go_left()),
ITEM('r', "Go Right", go_right()),
ITEM('f', "Go Forward", go_forward()),
...
и даже код для парсинга array-я struct'ов скроеного таким способом будет корркетный и читаемый, достаточно итерировать массив как обычно. А терь сделай это линейно в культурном виде, м? Могу представить себе какой трэш будет в коде и декларировании и сколько багов там можно будет выкусить. Это в принципе уже не так далеко от ООПшных фокусов, но еще не оно, ибо ничего оопшного, только struct, массивы да указатели на функции, которые ассемблерщика уж точно смущать не должны. Идея не моя, вольное цитирование по памяти мануала GCC, чтоли.

У плюсеров и т.п. есть и штуки даже покруче - итераторы.

> Что значить создать массив из N элементов с точки зрения асм или любую другую структуру?

Ну вон см. выше. Это конечно будет всего лишь генерацией одной большой константы, можно даже наглухо readonly в принципе (rodata). И конечно у нее есть sizeof Но вот ручками ее как плоский регион памяти парсить... придется сперва все абстракции самому запилить, потом, конечно, распарсится :)

> Что из себя представляет тот же C++-ный код в асм листинге? Что мешает писать на асм так
> же как и генерит компилятор?

То что в асме нет вон тех понятий.

> Компилятор лучше сделает? - не согласен.

А таки сделает. Если есть где развернуться. В мелком локальном закоулке обставить компилера можно, но сделать какой-нибудь LTO в более крупном коде да удачи. Он в отличие от - видит всю программу, может ДОКАЗАТЬ что та подветка никогда не вызывается и выпилить ее код совсем, заскипает перегрузки регистров, помня что кило назад уже была потребная константа от которой можно оттанцевать, и так далее. А на современных процах "удобной константой" к тому же может быть адресация вида [Rx+N] где в команду кодируется только (маленькое) N. Для человека же пачка смещений от базы не особо читаема.

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

Это сильно отдельная возня и к тому же отдельно от программы. Надо еще и переключаться между задачами. Неудобно. В продвинутых прогерских редакторах есть переход к определению. Так что если я забыл что такое wtf_data_t - ну, ок, после 1 хоткея я освежу свой склероз. Быстрее чем задачи переключать.

> чем сидеть и вчитываться в код какого-то непонятного мне формального языка. Да, все что вы
> говорите легче псевдокодом описать, а дальше сесть и написать инструкции к исполнению.

Я бы не сказал что это легче. Особенно под 5 разных архитектур. А чего ради я должен быть прибит на гвозди к одной?

> Допустим, человек умеет читать код (знаком с синтаксисом), но не знает предметную
> область, поможет ли ему "читабельность" кода? Промолчу про то, что "читабельный"
> код якобы не нуждается в комментариях.

Для вызова чужой библиотечной функции вообще не обязательно знать ее реализацию и быть вхожим в ту математику, надо знать лишь что на вход, что на выход и границы применимости. Это называется разделение труда. Это называется "разделение труда". И опять же позволяет реюз кода а также масштабирование далеко за пределы того что сможете лично вы. Можно не быть криптографом, но вызвать вон ту функцию писаную криптографом и она таки сделает все как надо. Более того, если я полезу выписывать это сам, 95% что наломаю дров неочевидным образом, область специфичная довольно. И если ей плотно не заниматься, легко облажаться. Вы наверное даже проверку пароля грамотно не сможете сделать так сразу.

Ну вот покажите псевдокод если есть password[30] который ввел юзер и const correct_password[30] с которым сравниваем, как вы проверите что юзер ввел верный пароль?

> Так сначала надо предметную область изучить, чтоб потом кодить.

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

> К вопросу "читабельности", всякая ли прочитанная книжка нам ясна с первого прочтения? Но не
> поняв прочитанного, мы грешим на автора.

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

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

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

> исполнение и отладка, формальные языки вообще отвергают понятие отладки, хотя у них

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

> есть понятие "покрытие тестами".

Это несколько другое на самом деле, хоть и связано. И да мне это нравится, для понимания правильно ли я вообще логику вон того блока кода оформил и не отъехало ли оно при рефакторе.

> прототипы, соглашение об вызовах все это формальные понятия.

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

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

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

> Лениво? а как же усердие? Знаете почему когда берут в ученики в
> Шаолиньский монастырь первые пол года ученик с метлой в руках подметает
> дворы, носит воду и т.д.?

Ну вот шаолиньским монахам и флаг в руки. Особенно если они заодно МакЛауды. А у меня одна жизня и делать 1 работу 5 раз я не хочу. Тем более что сделать 1 раз и 4 раза основательно улучшить - результат скорее всего будет лучше. Не всегда сразу понятен наилучший путь, иногда надо зарубуться с проблемой вплотную чтобы увидеть лучшее решение.

> То что код должен быть написан под все архитектуры это очевидность, а то что код
> должен быть написан на всех языках - маразм?

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

> баловался с МК на сях и ручками выставлял биты в регистрах, спрашивается
> зачем мне С, если тоже самое я делаю на асм?

На сях это можно делать ничуть не хуже. Более того - с препроцессором можно даже компилтайм все делать, precomputed константами и даже compile-time проверками. Когда просто не получится загнать число 22 в 3-битное поле регистра, которое может быть только 0..7 и компилер меня сразу отлупит при попытке это сделать. И я вижу что лажа вышла. Удачи так на асме... там недостаточно аннотации намерений для такого развлечения.

> а с проблемой ведь сталкиваемся не при прочтении "читабельного" кода, так ведь?

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

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

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

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

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

> почему навигация? описанный вами процесс - отладка (пусконаладка),

Это разные понятия. Обзор кода и его понимание может быть как-то связан с вон тем а может не быть. Может быть и патчингом поведения, реализацией какой-то фичи или чего еще.

> ну и не стоит забывать про профилирование, ибо внесенные изменения после
> обнаружения трабла могут регрессивно повлиять.

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

> а что представляет из себя struct в плоской памяти?

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

Более того - это дает некие проверки. Если скажем при рефакторе выпилили определенное поле решив что оно не так уж надо, а какой-то код попытается его юзать - на асме у вас будут трацыбацки. А тут просто компил завалится с "struct something doesn't haves member something_else". Какой код поддерживать лучше - думаю понятно.

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

Спасибо кэп. Просто это не самая удобная абстракция.

> а вот в С++ в структурах есть методы, классы какие-то, а в сях нет и т.д.

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

211. "Выпуск языка программирования Crystal 1.5"  –1 +/–
Сообщение от Тот_Самый_Анонимус (?), 28-Июл-22, 04:31 
> add(a, b) - норм ведь

Нет. Это снижает удобство чтения кода. Так же, как снижают его бегин и енд. Тогда и точку с запятой надо заменить на какой нибудь enf of instruction. По вашей логике (из следующих комментов) это равнозначно.

Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

214. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 28-Июл-22, 12:05 
>Тогда и точку с запятой надо заменить на какой
> нибудь enf of instruction. По вашей логике (из следующих комментов) это
> равнозначно.

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

Ответить | Правка | Наверх | Cообщить модератору

224. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Тот_Самый_Анонимус (?), 28-Июл-22, 19:11 
>кек, вашему парсеру без разницы какой символ будет разделителем инструкций

Я о людях говорю.

>Поэтому и говорю.

Хню говоришь. Чем лаконичнее запись, тем она понятнее. Если в качестве разделителя исполшьзовать не знак, а фразу, то читаемость глазом падает.

>что с точки зрения формальных языков для меня без разницы писать add(a, b) или a+b.

Тоже ложь. Если использовать выражение на десяток операторов, то читаемость падает в разы. особенно если это добротно приправлено скобками. А дополнительные скобки от add() ещё убавляют читабельности.

Стандарты кодирования не зря принимают.

Ответить | Правка | Наверх | Cообщить модератору

225. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 28-Июл-22, 19:39 
> Я о людях говорю.

люди разные от природы.

> Хню говоришь. Чем лаконичнее запись, тем она понятнее. Если в качестве разделителя
> исполшьзовать не знак, а фразу, то читаемость глазом падает.

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

> Тоже ложь. Если использовать выражение на десяток операторов, то читаемость падает в
> разы. особенно если это добротно приправлено скобками. А дополнительные скобки от
> add() ещё убавляют читабельности.

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

> Стандарты кодирования не зря принимают.

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

Ответить | Правка | Наверх | Cообщить модератору

250. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Тот_Самый_Анонимус (?), 30-Июл-22, 04:34 
> люди разные от природы.

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

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

Ради понимания. А ты?

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

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

Тем более что всякие begin, end, or, and интуитивно не понятны и требуют понимания иностранного языка.

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

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

Ответить | Правка | Наверх | Cообщить модератору

226. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 28-Июл-22, 19:59 
>add() ещё убавляют читабельности.

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


Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

228. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 28-Июл-22, 20:57 
> я посмотрю как вы читать будете когда ваш формальный язык позволяет перегружать
> операторы, a+b оказывается не арифметическое сложение.

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

Ответить | Правка | Наверх | Cообщить модератору

236. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Sw00p aka Jerom (?), 28-Июл-22, 23:37 
> Тут да, можно откушать если кодил долбоклюй.

ну язык ведь не запрещает, и не требует - мол оператор + перегружай всегда если он несет логически понятие сложения. Вы же так же будете считать долбоклюем того кто именует функции "нечитабельными" названиями, хотя это не запрещено. Хотя разобраться, что на самом деле делает та или иная функция возможно только если прочесть ее код, а не именование. Картинка мем есть такая про функцию fn random () { return 4; }
Ну вот есть название, функция рандома, а на самом деле это разве функция рандома?  :)

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

конечно можно, согласен, но я заранее об этом должен знать как-то.

> В общем-то не бывает так
> что энное решение идет с одними минусами или одними плюсами, обычно
> это по факту tradeoff.

ну тогда и не нужно быть в этом вопросе принципиальным, повторюсь, мне лично все равно писать add(a,b) или a+b, в языке так определили - значить так тому и быть. Имею ли я право говорить, вот китайский язык такой плохой, а мой родной такой лаконичный? - нет.

Ответить | Правка | Наверх | Cообщить модератору

248. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 30-Июл-22, 00:35 
> ну язык ведь не запрещает, и не требует - мол оператор +
> перегружай всегда если он несет логически понятие сложения.

Power comes with responsibility...

> Ну вот есть название, функция рандома, а на самом деле это разве
> функция рандома?  :)

Так можно на чем угодно облажаться и вот тут мы начинаем догадываться зачем существуют тесты. Эти уже могут более продвинуто прозвонить что то что random выдает хотя-бы похоже на рандом. Или если это детерминированный PRNG, что тестовые вектора правильные с вон тем seed'ом.

> конечно можно, согласен, но я заранее об этом должен знать как-то.

Тут возможно есть некое поле для улучшений.

> лично все равно писать add(a,b) или a+b, в языке так определили
> - значить так тому и быть.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

252. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Тот_Самый_Анонимус (?), 30-Июл-22, 04:44 
> ну тогда и не нужно быть в этом вопросе принципиальным, повторюсь, мне лично все равно писать add(a,b) или a+b, в языке так определили - значить так тому и быть.

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

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

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


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

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

Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

251. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Тот_Самый_Анонимус (?), 30-Июл-22, 04:35 
>>add() ещё убавляют читабельности.
> я посмотрю как вы читать будете когда ваш формальный язык позволяет перегружать операторы, a+b оказывается не арифметическое сложение.

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

Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

253. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Аноним (-), 31-Июл-22, 17:05 
На самом деле такая проблема есть, иногда "+" при перегрузке могут реально заменить на WTF какой-то. Типа конкатенации строк и тому подобного, порой весьма контринтуитивного относительно логики этого действа. Скажем если (a+b) != (b+a) это не очень то ожидаемо большинством кодеров. Круто же когда типа-сложение вдруг не коммутативно. Известный способ прострела пяток плюсерами, однако.
Ответить | Правка | Наверх | Cообщить модератору

254. "Выпуск языка программирования Crystal 1.5"  +/–
Сообщение от Тот_Самый_Анонимус (?), 01-Авг-22, 23:29 
> На самом деле такая проблема есть, иногда "+" при перегрузке могут реально заменить на WTF какой-то.

Разумеется. Каки имя функции не зависит от её содержания. Но это вопрос адекватности кодера.

> Типа конкатенации строк и тому подобного, порой весьма контринтуитивного относительно логики этого действа. Скажем если (a+b) != (b+a) это не очень то ожидаемо большинством кодеров. Круто же когда типа-сложение вдруг не коммутативно. Известный способ прострела пяток плюсерами, однако.

Ну всё же сложение строк весьма ожидаемо и коммуникативности от неё мало кто ждёт.


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру