идеальный язык программирования , каким он должен быть?

Цитата AndNot @ 08.10.06, 13:34

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

в С++ это есть

Добавлено 08.10.06, 13:42
то же Страуструп говорит об этом

Добавлено 08.10.06, 13:45

Цитата AndNot @ 08.10.06, 13:34

Никто ведь не запрещает тебе использовать *char, *void, etc. И ведь используют.

это методы чистого СИшника, на С++ так никто уже не делает, причем давно
void* - считается плохим стилем, решается наследованием, шаблонами и т.д.
char* - уже давно обернут в std::string

Добавлено 08.10.06, 13:47

Цитата AndNot @ 08.10.06, 13:34

Хорошо, вот нашел:

switch (len % 8) {
case 0: {
do { HAL_IO_PORT = *pSource++;
case 7: { HAL_IO_PORT = *pSource++; }
...
case 1: { HAL_IO_PORT = *pSource++; }
} while (--n > 0);
}
}


Что на это скажешь? Пример вполне реальный.

это пример из Страуструпа -причем учебный, лишь для понятия работы указателей

Добавлено 08.10.06, 13:48
причем тут слишком много лишних скобок фигурных

Добавлено 08.10.06, 13:50

Цитата impik777 @ 08.10.06, 13:42

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

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

Добавлено 08.10.06, 13:51

Цитата AndNot @ 08.10.06, 13:34

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

на С++ расшираяемость то же безграничная, но на уровне семантики, а не синтаксиса

Сообщение отредактировано: impik777 - 09.10.06, 10:19

Цитата AndNot @ 08.10.06, 13:34

Никто ведь не запрещает тебе использовать *char, *void, etc. И ведь используют. А одно это уже хороший источник багов.

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

Цитата mo3r @ 07.10.06, 19:22

что нельзя написать на ассемблере то вообще нельзя написать

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

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

Цитата mo3r @ 08.10.06, 03:32

Что, получается, что лисп — идеальный язык??

Ну, многие люди его так и позиционируют. Вот, например, статья: http://www.computerra.ru/hitech/35042/ . Эх, вот найду хорошее введение в лисп на русском языке, возьму и выучу.

В этой связи интересно, что, насколько я знаю, ни один человек, занимающийся серьёзно С/С++-подобными языками, не говорит о том, что они близки к идеальным.

Цитата mo3r @ 08.10.06, 03:32

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

Напиши свои! В общем, разговор для этого и заводился.

Цитата

1. Малый размер компилятора (чтоб свой проект всюду таскать с собой на дискетке).
2. Компактный синтаксис. Т.е. что бы на экране увидеть как можно больше, а не убивать жизнь, листаю сорсы вверх-вниз.
3. Расширяемость синтаксиса. Должна быть возможность создавать свой, для каждой конкретной задачи, и убирать ненужный.
4. Средства для тестирования, как на уровне модулей, так и отдельных подпрограмм (для этого лучше интерпритатора еще ничего не придумали).
5. Удобные средства обработки ошибок времени исполнения программы (которыми можно удобно управлять, изменять, добавлять, убирать).
6. Возможность использовать наработки с других языков.
7. Хорошая документация, с примерами

Пункты 1-5 явно списаны с Форта, 6-7 - общие требования. От себя ещё добавлю:

8. Однозначность синтаксиса. Чтобы по виду кода можно было бы однозначно сказать, что он делает, без рытья в тысячестраничной документации. (этим часто грешит С/С++)
9. Возможность написания как высоко-, так и низкоуровневого кода. (насколько я понимаю, Лисп этому требованию принципиально не удовлетворяет)
10. Возможность (лёгкость!) проектирования на том же языке. (специально для impik777) (опять же, читайте Броуди)
11. Лёгкость внесения изменений в алгоритм программы.
12. Простота синтаксиса (и соответственно простота освоения языка).

Цитата impik777 @ 08.10.06, 09:17

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

Так скажи об этом!

Цитата impik777 @ 08.10.06, 09:17

как раз таких СИшников расстреливают на месте, без права оправдания

И кто же их расстреливает?

Цитата impik777 @ 08.10.06, 13:42

на С++ расшираяемость то же безграничная, но на уровне семантики, а не синтаксиса

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

Цитата Hryak @ 08.10.06, 14:27

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

Насколько я понял, речь идёт о том, что в С/С++ контроль типов не спасает от ошибок.

Цитата AndNot @ 07.10.06, 21:33

Что невозможно написать на СИ то можно написать на фортране

Потому он еще и жив

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

Сообщение отредактировано: wormball - 09.10.06, 14:24

Цитата wormball @ 09.10.06, 14:22

Насколько я понял, речь идёт о том, что в С/С++ контроль типов не спасает от ошибок.

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

Добавлено 09.10.06, 17:00

Цитата wormball @ 09.10.06, 14:22

И кто же их расстреливает?

в принципе коллеги-программисты

Добавлено 09.10.06, 17:08

Цитата wormball @ 09.10.06, 14:22

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

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

Добавлено 09.10.06, 17:10

Цитата wormball @ 09.10.06, 14:22

10. Возможность (лёгкость!) проектирования на том же языке. (специально для impik777) (опять же, читайте Броуди)

наследование, перегрузка операторов, виртуальные фунции, интерфейсы .........
это только звучит страшно

Добавлено 09.10.06, 17:16
не хочу хвастаться и выпендриваться, но насчет сложности языка:
С++(чистый) изучил за 1 месяц без проблем, при полной нагрузке
зная до него лишь бейсик
просто не надо вдумываться в синтаксис и зубрить его,
а надо понять идеологию
ведь

Цитата AndNot @ 08.10.06, 13:34

switch (len % 8) {
case 0: {
do { HAL_IO_PORT = *pSource++;
case 7: { HAL_IO_PORT = *pSource++; }
...
case 1: { HAL_IO_PORT = *pSource++; }
} while (--n > 0);
}
}

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

return ++i++;

это не значит, что это нужно

Сообщение отредактировано: impik777 - 09.10.06, 17:24

Цитата wormball @ 09.10.06, 14:22

Насколько я понял, речь идёт о том, что в С/С++ контроль типов не спасает от ошибок.

От всех ошибок, естественно, не спасает. Но от очень многих...

Цитата impik777

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

return ++i++;

это не значит, что это нужно

Так, кстати, писать как раз нельзя.

Цитата wormball @ 09.10.06, 14:22

Пункты 1-5 явно списаны с Форта, 6-7 - общие требования.

Поклеп!!!! Но красиво жить не запретишь

Цитата impik777 @ 09.10.06, 16:59

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

Ты внимательно посмотри на расстановку скобок!!!!
Это не вяжется с идеей блочного программирования! Тем не менее на Сях это работает

Цитата Hryak @ 09.10.06, 19:00

От всех ошибок, естественно, не спасает. Но от очень многих...

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

Цитата AndNot @ 09.10.06, 20:40

Ты внимательно посмотри на расстановку скобок!!!!

скобки то зачем ??????

Добавлено 10.10.06, 13:24

Цитата Hryak @ 09.10.06, 19:00

Так, кстати, писать как раз нельзя.

можно так

return (++i)++;

Цитата AndNot @ 09.10.06, 20:40

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

Эта вероятность хорошо компенсируется опытом. Язык С++ очень простым назвать нельзя, он довольно труден для изучения.
И касаемо С++, трудность в изучении не коррелирует с трудностью в использовании. Просто нужно знать язык и пользоваться его мощью правильно. И не допускать ошибок вроде той, что сделал impik777.

Цитата

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

Не больше? Для одного и того же проекта?

Цитата impik777

можно так

return (++i)++;

И так нельзя. Запрещается дважды модифицировать один и тот же объект в выражении.

Цитата Hryak @ 10.10.06, 14:55

Цитата (impik777)
можно так

return (++i)++;


И так нельзя. Запрещается дважды модифицировать один и тот же объект в выражении.

VC++ 6.0 скомпилировала и выполнила

Добавлено 10.10.06, 15:25

Цитата Hryak @ 10.10.06, 14:55

И не допускать ошибок вроде той, что сделал impik777.

какую ?

//---------------------------------------

Добавлено 10.10.06, 15:36

int foo()
{
    int i = 0;
 
    return (++i)++;
}
 
void main()
{  
       cout << foo() << endl;    
}

Цитата

Вывод: 1

Сообщение отредактировано: impik777 - 10.10.06, 15:38

Цитата impik777 @ 10.10.06, 15:24

VC++ 6.0 скомпилировала и выполнила

Молодец она, что выполнила. А могла и винт форматнуть, ибо undefined behavior ожидалось.

Завязываем с оффтопиком....

Цитата impik777 @ 10.10.06, 12:53

Цитата (AndNot @ 9.10.06, 23:40)
Ты внимательно посмотри на расстановку скобок!!!!

скобки то зачем ??????

А затем, что 'case 7 ... case 1' выполняется в блоке 'do ... while', а 'case 0' как и положено в блоке 'switch ... while'. В блочном программировании такое недопустимо.

Цитата Hryak @ 10.10.06, 14:55

Эта вероятность хорошо компенсируется опытом. Язык С++ очень простым назвать нельзя, он довольно труден для изучения.

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

Цитата Hryak @ 10.10.06, 14:55

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

А для этого в нем не должно быть неоднозначностей. Добавь сюда человеческий фактор (когда к примеру из-за усталости пишут I++ вместо ++I, или пресловутая операция == ).

Цитата Hryak @ 10.10.06, 14:55

Цитата
Ведь на асме вообще отсутствует контроль типов, но ошибок не больше чем на ЯВУ.

Не больше? Для одного и того же проекта?

А ты попробуй, а потом говори К тому же:

Цитата Hryak @ 10.10.06, 14:55

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

А в асме все предельно четко и однозначно.

Цитата Hryak @ 10.10.06, 19:04

Цитата (impik777 @ Вчера, 18:24)
VC++ 6.0 скомпилировала и выполнила

Молодец она, что выполнила. А могла и винт форматнуть, ибо undefined behavior ожидалось.

Чем не пример излишеств C/С++?

Цитата AndNot, 11.10.2006, 23:53:41, 1299769

А в асме все предельно четко и однозначно.

Ты предлогаешь согласится что язык машины (asm) является идеальным для человека?

Цитата AndNot, 11.10.2006, 23:53:41, 1299769

А ты попробуй, а потом говори

Я бы тебе не советовал Hryak(у) рассказывать за количество ошибок. Ты говоришь несуразное в данном случае.

Цитата AndNot, 11.10.2006, 23:53:41, 1299769

Добавь сюда человеческий фактор (когда к примеру из-за усталости пишут I++ вместо ++I, или пресловутая операция == ).

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

Цитата AndNot @ 11.10.06, 20:53

А затем, что 'case 7 ... case 1' выполняется в блоке 'do ... while', а 'case 0' как и положено в блоке 'switch ... while'. В блочном программировании такое недопустимо.

посмотри этот же пример в Страуструпе !!!!!!!!

Добавлено 12.10.06, 06:14

Цитата AndNot @ 11.10.06, 20:53

Чем не пример излишеств C/С++?

вообще-то речь тут шла не об этом

Добавлено 12.10.06, 06:20

Цитата impik777 @ 08.10.06, 13:42

case 7: { HAL_IO_PORT = *pSource++; }

скобки здесь - полное извращение !!!

Добавлено 12.10.06, 06:25

Цитата AndNot @ 11.10.06, 20:53

Добавь сюда человеческий фактор (когда к примеру из-за усталости пишут I++ вместо ++I, или пресловутая операция == ).

А на Форте ты забудешь какой тип данных у тебя в данный момент,
а комп не проконтролирует....

Сообщение отредактировано: impik777 - 12.10.06, 06:25

По САБЖу
Идеального нет! И быть не может впринципе. Ибо идеальный должен учитывать все эти подходы а именно:
1) Процедурное программирование
2) Объектно-ориентированное программирование
3) Функциональное программирование
4) Логическое программирование
т.е. такой язык говоря языком простым должен быть повернут и в сторону машины и в сторону человека одновременно! А это невозможно. Пока...

Цитата Maksim @ 12.10.06, 03:09

Ты предлогаешь согласится что язык машины (asm) является идеальным для человека?

Если ты не пишешь какой нибудь загрузчик МБР, то конечно далеко не идеальный.

Цитата Maksim @ 12.10.06, 03:09

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

А до этого? Писать то надо, а

Цитата AndNot @ 11.10.06, 20:53

опытными не рождаются.

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

Цитата impik777 @ 12.10.06, 06:13

посмотри этот же пример в Страуструпе !!!!!!!!

Какая разница кто писал, просто факт налицо.

Цитата impik777 @ 12.10.06, 06:13

Цитата (impik777 @ 8.10.06, 16:42)
case 7: { HAL_IO_PORT = *pSource++; }

скобки здесь - полное извращение !!!

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

Цитата impik777 @ 12.10.06, 06:13

А на Форте ты забудешь какой тип данных у тебя в данный момент,
а комп не проконтролирует....

На Форте сам вставляешь контроль (если он нужен). К тому же на арифметическом стэке все данные - это CELL (под 32-х битной системой - соответственно 32-х разрядный).Прибавь сюда возможность данных самим класть свое значение на стэк, самим контролировать диапозон и тд., и отпадет необходимость помнить их тип.

Цитата best_lamer @ 12.10.06, 07:02

1) Процедурное программирование
2) Объектно-ориентированное программирование
3) Функциональное программирование
4) Логическое программирование

Если все это вставить в один язык, то его изучать пол жизни будешь. Да и большинству все это вместе как правило не нужно, нужно 1-2 пункта.
Лучше уж сделать язык, в котором изначально есть минимум. А если какая либо задача требует, к примеру, ООП, то достаточно подключить либу обеспечивающую эти функции. Если ООП не нужно, можно просто подключить просто процедурные функции, и тд. Собственно к этому очень близок Форт. В нем изначально нет ничего, кроме работы со стеками, поддержки многозадачности и простенькой обработки ошибок. Но сам видел либы, при подключении которых появляются ООП(и как в паскале и как С++), списки, структуры (в нем нет даже этого!), мощная обработка ошибок и прочее. Нашел либы которые преобразуют Форт в бейсик, паскаль, оберон, я уж не говорю про асм, т.е. меняют сам синтаксис языка до неузнаваемости. Неслучайно есть Форт-процессоры, он действительно может быть в основе всего. Хотя и у него конечно есть проблемы.