Войти
ФлеймФорумПрограммирование

Имеет ли смысл вводить следующие изменения в С? (4 стр)

Страницы: 13 4 5 613 Следующая »
#45
20:09, 6 мая 2019

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


#46
20:29, 6 мая 2019

Bakuard
Попробую перечислить основные качества языка C (некоторые из них уже морально устарели).

1. Это, практически, простейший из возможных компиляторов. Благодаря этому он "прозрачен" для программиста, вплоть до того, что полученный код можно править напильником.
2. Ему и не нужна большая сложность, т.к. он служит инструментом, скрепляющим  bash-скрипты. Поэтому изначально "его библиотеки" - это библиотеки самой ОС.
3. Для возможности развития этой роли к С добавлены компиляторы компиляторов.
4. Для удобства "скрепления" в C введена полная доступность адресов для арифметических операций. И типизация оставлена в зачаточном состоянии.
5. Для возможности пользоваться самодельным синтаксисом добавлен препроцессор.
6. Предприняты меры для возможности строить сложные программы путем масштабирования - объединения маленьких кусков кода и данных в большие.

Все предлагаемые Вами усиливают качество (6), но противоречат всем остальным.

#47
21:08, 6 мая 2019

gudleifr, получается общий принцип такой - оставляем только то, без чего нельзя обойтись, т.е. к примеру, если try-catch-finally можно заменить чем-то вроде

int myFunction(int argument, int* exceptionCode);

и после вызова функции всегда ставить if и проверять exceptionCode, то try-catch-finally как конструкцию - выкидываем?

Все предлагаемые Вами усиливают качество (6), но противоречат всем остальным.

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

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

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

#48
21:10, 6 мая 2019

Bakuard
> И касательно строк - диапозона char не всегда хватает что-бы вместить все
> символы которые используются в программе
А что мешает использовать UTF-8 в char*?

#49
21:27, 6 мая 2019

Bakuard
> try-catch-finally
Ну, как бы, само появление этой конструкции сомнительно. Типа, сначала мы насилуем Дейкстру, доказывая, что "один вход и один выход - это хорошо", а затем добавляем запасной выход... Отдает быдлокодингом. А почему не сопрограммы? Почему не конечные автоматы?
Тем более, что появление в программе исключений обычно символизирует отказ/невозможность программиста управлять кодом (из-за избыточного масштабирования).
Плюс, C имеет гораздо более мощный инструмент - построение таблиц адресов функций, которое позволяет писать код, полностью управляемый данными.

Bakuard
> Вот не могу понять, как конвенция по именованию (под конвенцией я подразумеваю
> просто соглашение между программистами по оформлению кода) противоречит
> приведенным вами принципам?
Она полностью соответствует программированию методом масштабирования, мешает быдлокодингу, избыточна для структурного программирования, мешает построению проблемно-ориентированных языков. 2.5 : 1.5 в пользу отказа.

Bakuard
> С используется также для программ, где необходимо поддержка нескольких языков
Тут только один выход: использовать то внутреннее представление, что соответствует логике программы, а "человеческое кодирование" считать проблемой исключительно интерфейсной - "перекодировать непосредственно перед printf".

#50
21:38, 6 мая 2019

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

• Trust the programmer.
• Don’t prevent the programmer from doing what needs to be done.
• Keep the language small and simple.
• Provide only one way to do an operation.
• Make it fast, even if it is not guaranteed to be portable.

#51
(Правка: 6:49) 6:49, 7 мая 2019

exchg
> • Trust the programmer.
> • Don’t prevent the programmer from doing what needs to be done.
> • Keep the language small and simple.
> • Provide only one way to do an operation.
> • Make it fast, even if it is not guaranteed to be portable.
Забавно, но при разработке Ü я исхожу из прямо противоположных принципов.

• Программисту доверять нельзя. Программист - простой смертный, который склонен ошибаться, поэтому надо много раз проверять, что он этого не сделал.
• Во избежание ошибок нельзя давать программисту выполнять опасные операции, если ему очень надо, пусть подвердит своё согласие на это через unsafe.
• Простой язык не даёт возможности надёжно писать большие программы. Поэтому неизбежно в языке возникает сложность, как способ такие программы писать с приемлемыми трудозатратами и качеством.
• Один способ сделать что-то - практически невозможно при возникающей сложности языка. Да, простейший код типа алгоритмов будут почти всегда писать одним способом, но вот архитектура сложной программы будет разная у разных программистов.
• Скорость в угоду портабильности - нафиг не надо в языке. Если всё-же надо добиться максимальной скорости в ущерб переносимости, программист должен явно написать unsafe код с непортабельными типами для этого.

#52
(Правка: 7:00) 6:59, 7 мая 2019

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

избыточна для структурного программирования, мешает построению проблемно-ориентированных языков.
#53
(Правка: 8:28) 8:21, 7 мая 2019

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

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

Panzerschrek[CN]
> Забавно, но при разработке Ü я исхожу из прямо противоположных принципов.

Броуди 30 | Имеет ли смысл вводить следующие изменения в С?
#54
16:44, 7 мая 2019

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

#55
(Правка: 19:17) 19:16, 7 мая 2019

1-7 - не нужно.
Нужны ссылки и const модификаторы. В остальном он идеален. С сахаром прекрасно справляются макросы.

#56
19:19, 7 мая 2019

Dampire
> Нужны ссылки и const модификаторы.
Да, этого будет достаточно, чтобы утонуть в дерьме крестопроблем.

#57
19:22, 7 мая 2019

gudleifr
Утопись уже в ложке воды наконец, ты всем надоел. Записку не забудь оставить.

#58
20:23, 7 мая 2019

Dampire
> Нужны ссылки
Одновременное наличие в языке указателей и ссылок — это, скорее, недостаток.

#59
20:45, 7 мая 2019

}:+()___ [Smile]
> Одновременное наличие в языке указателей и ссылок
Ссылки умеют штуку, которую не умеют указатели - позволяют переопределять оператор присваивания. Но в C нет перегрузки операторов...

Страницы: 13 4 5 613 Следующая »
ФлеймФорумПрограммирование