Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
>Процесс разработки ПО и ЯП 04.05.04 12:44 Число просмотров: 3282
Автор: null666 Статус: Незарегистрированный пользователь
|
> Процесс разработки ПО и ЯП
> Костин Г.В.
> Все в этой книге может оказаться ошибкой.
> Р. Бах. Иллюзии
"Каждый имеет право написать книгу и каждый имеет право её не читать!" (с)кто-то неглупый
Господи, очередной "критик" с претензиями к "плюсам". Вы случаем на http://www.delphikingdom.ru не ошиваетесь? Слишком уж пропахший стиль. Попытки тщательно замаскировать дифирамбы Виртовским языкам не удались - заметили, имхо, все.
Применю грязный приём (оттуда же): если он Вам так не нравится, то какого чёрта Вы про него пишите? Не можете бросить? Ну бывает... Процесс разработки ПО говорите? Ну что же, я согласен, написано у Вас немножко (судя по скроллу - 30% статьи - не больше). За исключением прямоугольника - давно известные факты. Может быть следовало как-то расширить этот раздел?
>Лёгкость понимания программы человеком. Компьютер программу компилирует, а читает и
>модифицирует её человек. Успешность этого процесса в значительной степени зависит от легкости
>понимания программы. В частности, синтаксиса языка. "
Полностью согласен. И вот тут-то как раз языки Вирта сливают. Они разработаны не для человека - они разработаны для компилятора. От и до. Я не знаю каким нужно быть извращенцем, чтобы заменить наиболее часто используемый оператор присваивания на крайне трудную в наборе последовательность. Зато с точки зрения компилятора - абсолютно всё равно и крайне удобно. Крайняя линейность и рубленность конструкций (чаще всего не более двух-трёх операций в строке), безусловно выравнивает ситуацию с чтением программ, но ощущение, что ты вынужден размеренно шагать по коридору выбранному компилятором - не покидает. Modula и Oberon (знаком только по спецификациям и публикациям на пресловутом http://www.delphikingdom.ru) вызывают абсолютно те же чувства.
>ЯП языки - явление прежде всего социальное, а научное. Умозрительные критерии и оценки
>достоинств и недостатков языков, по меньшей мере, неубедительны - основной критерий: практика
> массового использования.
Перед словом "научное" видимо пропущено "не".
Вы идёте по скользкой дорожке перманентной критики а-ля Windows из разряда "ёжики плакали, кололись, но продолжали есть кактус". Массовость использования отнюдь не показатель.
>Единственное требование к использованию языка - это адекватность применения.
А вот это уже на 5 баллов! ^_^ b
>Наиболее верный путь к успеху - использование чистого объектно - ориентированного языка
Использование чистых объектно-ориентированных языков также не приводит ни к чему хорошему. Автор (Ян Джойнер) либо апологет чистого объектно-ориентированного подхода, либо ни разу не программировал на чистых объектно-ориентированных языках. Использование бесконечных классов, интерфейсов и пр. перегружает программу как лексически, так и логически. Банальное описание точки входа в программу занимает половину экрана. Спор из разряда goto и рекурсии. Да, без этого вполне можно обойтись, но порой решение с применением данных парадигм является самым простым и понятным.
>На x86, к примеру, это ничего не дает. И A=B++ и A:=B; inc(b); приведут к командам ассемблера
>MOV a,b; inc b
Неправда Ваша. Во-первых в Виртовских языках идеологически верным является написание A:=B; B:=B+1; Во-вторых то что Вы привели в качестве примера ассемблерного аналога - не более, чем дань моде и необходимости. Причём хочется заметить, что Паскалевская конструкция inc(b); вовсе необязательно будет интерпретирована как ассемблерная инструкция inc b - дело в том, что inc является библиотечной функцией, а посему её поведение никоим образом не зависит от Ваших (да и Вирта тоже) желаний.
>Вирт писал что : "...язык должен определяться в терминах математических, абстрактных концепций
>И только, если язык удовлетворяет этому критерию, он может считаться высокоуровневым."
Встречалось. Только вот в математических абстрактных концепциях нет места такой банальщине, как inc, оптимизация челочисленного умножения путем замены сдвигом битового представления числа... Да что там говорить - в математике понятием класса и то не пооперируешь. Видимо поэтому-то Вирт в своём развитии и остановился на уровне процедур - они вполне вписываются в стройные математические модели.
>Изменяющиеся от платформы к платформе размеры типов данных.
А что Delphi уже научился обеспечивать Integer одинаковым на всех платформах? Не смешите!
>int i=0,ar[2]={10,11};
>i=ar[i++];// А кто сразу скажет чему равно значение i
10. Столь любимая Виртом строгая математическая концепция приоритета операторов срабатывает безукоризненно. В отличие от следующей конструкции: IF a>4 AND a<6 THEN ...;
>Если заменить short int на longt int, то придется менять и printf("%d\n",x) на printf("%D\n",x)
Чуть выше был cout, а тут вдруг printf. Либо Вы грязно передёргиваете, либо сам себе злобный буратино. Оба случая полностью на Вашей совести.
>Отсутствует логический тип данных.
RTFM. Уже давным-давно существует.
>А что может значить, по Вашему мнению, команда a=24[ar]; ?
>При условии, что int ar[50]; int a; она полностью эквивалентна a:=ar[24];
Опять же с точки зрения математической логики - абсолютно верная конструкция. Ибо сложение, как водится, коммутативно - если Вы этого не знали - нужно было меньше в школе уроки прогуливать.
>Есть ли читатели, которые по - прежнему считают, что краткость - это всегда очень хорошо. А
>читабельность конструкций языка факт второстепенный ?
В качестве банальной тренировки можете также слепить строки в программке на Паскале, да ещё и на каком-нибудь архаичном диалекте времен приведённого Вами синтаксиса Кернигана и Ритчи. Получится не сильно читабельнее.
>Что вполне логично, т.к. проверка у процессоров 80x86 реализуются на аппаратном уровне.
Вы багтрак-то читаете? Если всё так шоколадно с аппаратной проверкой выхода за границы массива, то откуда все эти buffer overflow?
>Да и вынести низкоуровневый код, в отдельный модуль написанный, допустим, на ассемблере не
>составляет проблем
Вы пробовали это отлаживать??? Уж не говоря о том, что в этом случае нужен программист со знанием двух языков, ну или два программиста...
>Но ведь и заметного проигрыша тоже нет ?
Для некоторых задач и разница в 5% является крайне значимой.
В общем как уже сказал кто-то до меня - можно привести кучу подобных аргументов против Вирта. И правда напоминаете студента почему-то обидевшегося на С++.
|
|
<site updates>
|
Процесс разработки ПО и ЯП 11.10.03 19:59
Publisher: dl <Dmitry Leonov>
|
Процесс разработки ПО и ЯП
Костин Г.В.
Все в этой книге может оказаться ошибкой.
Р. Бах. Иллюзии
Здесь привожу некоторые фрагменты из проведенного мной анализа ЯП (несколько сот страниц; с охватом от Assembler до Zhell, от архитектуры процессоров до языков сценариев и от Fortran до C#). Обратная связь приветствуется. Будут интересны мнения, ссылки на литературу, конструктивная критика... Я с удовольствием рассмотрю предложения об обучении в вашем ВУЗе /участие в конференции/ работе связанной с анализом ЯП/Информации о заинтересованных лицах. E - mail автора: georgii"Nospam"@pisem.net. Естественно, перед отправкой писем строчку "Nospam" необходимо убрать.
С полным оглавлением данного исследования можно ознакомиться здесь. [ .keep/languages.content.html ]
Что есть язык?
Для начала ответим на вопрос: Что есть язык ?
Язык - это интерфейс между двумя субъектами
Примеры:
Человеческий язык - совокупность (слова, жесты, телодвижения, интонаций и мимики).
Интерфейсы (мышка, пользователя, API)
...
Полный текст
|
|
По-моему, у автора просто немного не сложилось с С и С++... 06.05.04 20:19
Автор: lzd Статус: Незарегистрированный пользователь
|
По-моему, у автора просто немного не сложилось с С и С++. ^_^
Во-первых, он их слабо различает. Во-вторых, явно нет серьезного опыта работы с этими языками.
А в-третьих, хотелось бы видеть больше запятых и меньше грамматических ошибок. Раз уж взялись серьезные статьи писать.
|
|
>Процесс разработки ПО и ЯП 04.05.04 12:44
Автор: null666 Статус: Незарегистрированный пользователь
|
> Процесс разработки ПО и ЯП
> Костин Г.В.
> Все в этой книге может оказаться ошибкой.
> Р. Бах. Иллюзии
"Каждый имеет право написать книгу и каждый имеет право её не читать!" (с)кто-то неглупый
Господи, очередной "критик" с претензиями к "плюсам". Вы случаем на http://www.delphikingdom.ru не ошиваетесь? Слишком уж пропахший стиль. Попытки тщательно замаскировать дифирамбы Виртовским языкам не удались - заметили, имхо, все.
Применю грязный приём (оттуда же): если он Вам так не нравится, то какого чёрта Вы про него пишите? Не можете бросить? Ну бывает... Процесс разработки ПО говорите? Ну что же, я согласен, написано у Вас немножко (судя по скроллу - 30% статьи - не больше). За исключением прямоугольника - давно известные факты. Может быть следовало как-то расширить этот раздел?
>Лёгкость понимания программы человеком. Компьютер программу компилирует, а читает и
>модифицирует её человек. Успешность этого процесса в значительной степени зависит от легкости
>понимания программы. В частности, синтаксиса языка. "
Полностью согласен. И вот тут-то как раз языки Вирта сливают. Они разработаны не для человека - они разработаны для компилятора. От и до. Я не знаю каким нужно быть извращенцем, чтобы заменить наиболее часто используемый оператор присваивания на крайне трудную в наборе последовательность. Зато с точки зрения компилятора - абсолютно всё равно и крайне удобно. Крайняя линейность и рубленность конструкций (чаще всего не более двух-трёх операций в строке), безусловно выравнивает ситуацию с чтением программ, но ощущение, что ты вынужден размеренно шагать по коридору выбранному компилятором - не покидает. Modula и Oberon (знаком только по спецификациям и публикациям на пресловутом http://www.delphikingdom.ru) вызывают абсолютно те же чувства.
>ЯП языки - явление прежде всего социальное, а научное. Умозрительные критерии и оценки
>достоинств и недостатков языков, по меньшей мере, неубедительны - основной критерий: практика
> массового использования.
Перед словом "научное" видимо пропущено "не".
Вы идёте по скользкой дорожке перманентной критики а-ля Windows из разряда "ёжики плакали, кололись, но продолжали есть кактус". Массовость использования отнюдь не показатель.
>Единственное требование к использованию языка - это адекватность применения.
А вот это уже на 5 баллов! ^_^ b
>Наиболее верный путь к успеху - использование чистого объектно - ориентированного языка
Использование чистых объектно-ориентированных языков также не приводит ни к чему хорошему. Автор (Ян Джойнер) либо апологет чистого объектно-ориентированного подхода, либо ни разу не программировал на чистых объектно-ориентированных языках. Использование бесконечных классов, интерфейсов и пр. перегружает программу как лексически, так и логически. Банальное описание точки входа в программу занимает половину экрана. Спор из разряда goto и рекурсии. Да, без этого вполне можно обойтись, но порой решение с применением данных парадигм является самым простым и понятным.
>На x86, к примеру, это ничего не дает. И A=B++ и A:=B; inc(b); приведут к командам ассемблера
>MOV a,b; inc b
Неправда Ваша. Во-первых в Виртовских языках идеологически верным является написание A:=B; B:=B+1; Во-вторых то что Вы привели в качестве примера ассемблерного аналога - не более, чем дань моде и необходимости. Причём хочется заметить, что Паскалевская конструкция inc(b); вовсе необязательно будет интерпретирована как ассемблерная инструкция inc b - дело в том, что inc является библиотечной функцией, а посему её поведение никоим образом не зависит от Ваших (да и Вирта тоже) желаний.
>Вирт писал что : "...язык должен определяться в терминах математических, абстрактных концепций
>И только, если язык удовлетворяет этому критерию, он может считаться высокоуровневым."
Встречалось. Только вот в математических абстрактных концепциях нет места такой банальщине, как inc, оптимизация челочисленного умножения путем замены сдвигом битового представления числа... Да что там говорить - в математике понятием класса и то не пооперируешь. Видимо поэтому-то Вирт в своём развитии и остановился на уровне процедур - они вполне вписываются в стройные математические модели.
>Изменяющиеся от платформы к платформе размеры типов данных.
А что Delphi уже научился обеспечивать Integer одинаковым на всех платформах? Не смешите!
>int i=0,ar[2]={10,11};
>i=ar[i++];// А кто сразу скажет чему равно значение i
10. Столь любимая Виртом строгая математическая концепция приоритета операторов срабатывает безукоризненно. В отличие от следующей конструкции: IF a>4 AND a<6 THEN ...;
>Если заменить short int на longt int, то придется менять и printf("%d\n",x) на printf("%D\n",x)
Чуть выше был cout, а тут вдруг printf. Либо Вы грязно передёргиваете, либо сам себе злобный буратино. Оба случая полностью на Вашей совести.
>Отсутствует логический тип данных.
RTFM. Уже давным-давно существует.
>А что может значить, по Вашему мнению, команда a=24[ar]; ?
>При условии, что int ar[50]; int a; она полностью эквивалентна a:=ar[24];
Опять же с точки зрения математической логики - абсолютно верная конструкция. Ибо сложение, как водится, коммутативно - если Вы этого не знали - нужно было меньше в школе уроки прогуливать.
>Есть ли читатели, которые по - прежнему считают, что краткость - это всегда очень хорошо. А
>читабельность конструкций языка факт второстепенный ?
В качестве банальной тренировки можете также слепить строки в программке на Паскале, да ещё и на каком-нибудь архаичном диалекте времен приведённого Вами синтаксиса Кернигана и Ритчи. Получится не сильно читабельнее.
>Что вполне логично, т.к. проверка у процессоров 80x86 реализуются на аппаратном уровне.
Вы багтрак-то читаете? Если всё так шоколадно с аппаратной проверкой выхода за границы массива, то откуда все эти buffer overflow?
>Да и вынести низкоуровневый код, в отдельный модуль написанный, допустим, на ассемблере не
>составляет проблем
Вы пробовали это отлаживать??? Уж не говоря о том, что в этом случае нужен программист со знанием двух языков, ну или два программиста...
>Но ведь и заметного проигрыша тоже нет ?
Для некоторых задач и разница в 5% является крайне значимой.
В общем как уже сказал кто-то до меня - можно привести кучу подобных аргументов против Вирта. И правда напоминаете студента почему-то обидевшегося на С++.
|
|
Процесс разработки ПО и ЯП 31.10.03 13:15
Автор: читатель Статус: Незарегистрированный пользователь
|
|
Абсолютно неясно, при чём здесь "Процесс разработки ПО и ЯП". Такое ощущение (извините за резкость), что автор - студент N-го курса, получивший "неуд" за знание С/С++, и теперь пытающийся убедить окружающих в том, что С/С++ сложный, малоупотребительный язык. А как,интересно , будет выглядеть статья по ассемблеру?
|
| |
Процесс разработки ПО и ЯП 12.11.03 15:26
Автор: Георгий Статус: Незарегистрированный пользователь
|
> Абсолютно неясно, при чём здесь "Процесс разработки ПО и
> ЯП".
А начало статьи ты не читал ?
Такое ощущение (извините за резкость), что автор -
> студент N-го курса, получивший "неуд" за знание С/С++, и
Вообще-то автомат у меня был по C++
> теперь пытающийся убедить окружающих в том, что С/С++
> сложный, малоупотребительный язык.
И приводящий при этом цитаты в его пользу.
А как,интересно , будет
> выглядеть статья по ассемблеру?
Ну вообщето есть такая глава. И критики в ней нет абсолютно.
|
|
Процесс разработки ПО и ЯП 16.10.03 12:04
Автор: Serge Sereda Статус: Незарегистрированный пользователь
|
> Процесс разработки ПО и ЯП
> Костин Г.В.
Начало статьи не соответствует её завершению. "Начали за здравие, а кончили за упокой".
Название: "Процесс разработки ПО и ЯП", а статья сведена к анализу плюсов и минусов "плюсов" (пардон за каламбур ;-)
Не учтены требования Законов Развития Технических систем (напр. http://cie.ase.md/~sereda/os_devel.htm или http://consumer.nm.ru/os_devel.htm).
Кроме того, крайне спорны утверждения об умении отдельных представителей Homo Sapiens Sapiens ходить по воде и превращать воду в вино ;-)
>Интересен сравнительный анализ ЯП и компиляторов и вообще всё
>что с этим связанно.
Вот описание полностью отечественной системы компиляции, интерпретации и анализа программ на С/С++, там частично приведён сравнительный анализ С++ и Ада95.
http://www.interstron.ru/txt/PaperEAZ_Autoref_Ru.htm
>В частности связь с психологией. Очень
>интересно отличие "у нас" и " за бугром".
С психологией технические системы не должны быть связаны никак.
Так же как и процесс их развития (http://www.bugtraq.ru/library/misc/invent.html).
>Интересуют также координаты людей и организаций, в чьи
>профессиональные и научные интересы входят ЯП.
Пока могу указать только http://www.interstron.ru/
С уважением,
Сергей Середа
serge_sereda 'at' hotmail.com
|
|
Процесс разработки ПО и ЯП 13.10.03 12:45
Автор: читатель Статус: Незарегистрированный пользователь
|
Процесс разработки ПО и ЯП ?
Совершенно непонятно почему автор выбрал такое название статьи.
На мой взгляд статья должна была бы называться как-то вроде "N-цать неубедительных аргументов, доказывающих, что С и С++ суть отстой".
|
|
Очень многое "притянуто за уши" 12.10.03 16:54
Автор: amirul <Serge> Статус: The Elderman
|
> Все в этой книге может оказаться ошибкой.
Например, мне было очевидно, что анализ не слишком непредвзятый. Автору не нравятся C/C++, но аргументы выбраны не самые лучшие.
Сначала возникло желание поквотить чуть ли не весь текст и прокомментировать с другой позиции (мне C/C++ нравятся). Потом сдержался :-), потому как потом бы самого себя оштрафовал бы за оверквотинг :-)
|
| |
интересно, сам автор пробовал скомпилировать программку-Basic? :))) 10.11.03 13:33
Автор: serg2 Статус: Незарегистрированный пользователь
|
нормальные компиляторы не пропускают switch (...) { break; ... }
и вполне справедливо сообщают что дальнейшие команды unreachable :)
это, увы, сильно подрывает доверие к уровню компетентности автора и его рассуждениям.
|
| | |
интересно ?-пробовал 12.11.03 15:23
Автор: Георгий Статус: Незарегистрированный пользователь
|
> нормальные компиляторы не пропускают switch (...) { break;
А я на ненормпльном GNU C по Linux ;)
И работает
|
| | | |
увы 29.12.03 12:45
Автор: serg2 Статус: Незарегистрированный пользователь
|
> А я на ненормпльном GNU C по Linux ;)
> И работает
ну дак и я на ненормальном:) конечно оно все поправимо и потом запускаемо, но в исходном виде (copy-paste из текста статьи) дает такой результат:
GNU C version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by GNU C version 2.95.4 20011002 (Debian prerelease).
test.c: In function `main':
test.c:12: parse error before `;'
test.c:13: warning: unreachable code at beginning of switch statement
test.c:15: parse error before `;'
---
|
| |
Не знаю, с некоторыми тезисами я вынужден согласиться. 12.10.03 17:01
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
|
Но анализ говорит о том, что автор занимался C/C++ весьма поверхностно. Фраза "Элементарные операции со строками требуют знакомства с STL и шаблонами." меня порядком развлекла :)
|
| | |
C *некотороми* и я согласен. 12.10.03 18:01
Автор: amirul <Serge> Статус: The Elderman
|
> Но анализ говорит о том, что автор занимался C/C++ весьма
> поверхностно. Фраза "Элементарные операции со строками
> требуют знакомства с STL и шаблонами." меня порядком
> развлекла :)
Но сейчас просто что вспомню:
1) Два простейших цикла до 4-х миллиардов и рандом внутри. Скорость зависит от реализации самого rand, а не от того как язык компилит циклы (уж
это умеет делать компилятор любого языка). Если бы там был "правильный" рандом на MD5 к примеру, разница в скорости была бы еще больше.
2) Мутная прога. Непонятную программу можно написать на любом языке (и на виртовской линейке тоже), а вот эффективную - не всегда. То что это МОЖНО сделать не значит, что это следует делать.
3) for, который на самом деле можно сделать while-ом: покажите такой язык программирования, где нельзя.
4) Избыточность. То бишь наличие в C++ сходных и по функциям и (самое интересное) по получаемым результатам механизмов. Спорно. Чаще всего те или иные механизмы позиционируются на разных участках шкалы скорость-используемая память. Практически любую задачу, реализованную с помощью виртуальных функций можно переписать на шаблонах и наоборот, но шаблоны совсем не то же самое, что виртуальные функции.
5) Множственное наследование. Как аргумент против него: возможна ситуация, которую придется обходить. Ага. А если жить на улице, то квартиру не ограбят. Кроме того, вилкой можно выколоть себе глаз, так что давайте есть руками. Множественное наследование не исключает одиночное, а дополняет его. Никто не заставляет пользоваться множестенным наследованием, если не умеешь.
6) Критика printf-а. Следует различать сам язык и его библиотеку (хотя она тоже входит в стандарт языка). printf является обычной функцией, реализованной на языке. Иначе реализовать было просто нельзя. В паскале же ввод/вывод вообще введен в сам язык (в этом месте можно перечитать аргументы против страуструповского желания ввести в C++, причем не в язык, а в библиотеку, инстременты для создания GUI и работы с DB - автор непоследователен, вирту можно, страуструпу нельзя)
7) Для меня END LOOP ничуть не более понятен, чем } (если циклов, скажем штуки 4), но при этом набирать его гораздо дольше. Для обеспечения понятности во первых принято за закрывающей скобкой писать комментарий, к чему она относилась, во вторых все современные IDE позволяют быстро перейти к парной скобке - посмотреть чего там такое и вернуться обратно. Причем делается это горячими клавишами за пару секунд.
И т.д.. Сейчас больше не вспомню. Кое какие аргументы действительно имеют резон, но БОЛЬШИНСТВО не выдерживают критики. Скажем так, я встречал и более качественную критику C++, к которой я подкопаться не мог. Точно так же как встречал критику паскаля и других виртовских языков.
|
| | | |
C *некотороми* и я согласен. 12.10.03 21:32
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
> 3) for, который на самом деле можно сделать while-ом:
> покажите такой язык программирования, где нельзя.
Не. Речь о том, чтобы использовать for для обхода некоего набора величин. А там товарищ привел классическую для C бяку, когда начинающие в приращение цикла начинают пихать что ни попадя. Действительно не слишком хорошая вещь, хотя в ряде случаев как раз эта возможность может быть весьма полезной. В общем, как обычно - любым мощным инструментом надо уметь пользоваться...
> 4) Избыточность. То бишь наличие в C++ сходных и по
> функциям и (самое интересное) по получаемым результатам
> механизмов. Спорно. Чаще всего те или иные механизмы
> позиционируются на разных участках шкалы
> скорость-используемая память. Практически любую задачу,
> реализованную с помощью виртуальных функций можно
> переписать на шаблонах и наоборот, но шаблоны совсем не то
> же самое, что виртуальные функции.
Ну нет, про виртуальные функции и шаблоны я категорически не согласен, но об этом в аську либо в приват, потому что это долго :)
> 5) Множственное наследование. Как аргумент против него:
> возможна ситуация, которую придется обходить. Ага. А если
> жить на улице, то квартиру не ограбят. Кроме того, вилкой
> можно выколоть себе глаз, так что давайте есть руками.
> Множественное наследование не исключает одиночное, а
> дополняет его. Никто не заставляет пользоваться
> множестенным наследованием, если не умеешь.
Ну здесь я опять-таки не могу однозначно сказать что-то. В целом я вынужден согласиться с автором статьи, что множественное наследование - да, спорно. Причем и идея, и реализация в случае C++. По сравнению, например, с CLOS, в C++ множнаследование выглядит убого.
> 6) Критика printf-а. Следует различать сам язык и его
> библиотеку (хотя она тоже входит в стандарт языка). printf
> является обычной функцией, реализованной на языке. Иначе
> реализовать было просто нельзя. В паскале же ввод/вывод
> вообще введен в сам язык (в этом месте можно перечитать
> аргументы против страуструповского желания ввести в C++,
> причем не в язык, а в библиотеку, инстременты для создания
> GUI и работы с DB - автор непоследователен, вирту можно,
> страуструпу нельзя)
Ну там автор вообще плохо провел черту между языком и библиотекой :)
> 7) Для меня END LOOP ничуть не более понятен, чем } (если
> циклов, скажем штуки 4), но при этом набирать его гораздо
> дольше. Для обеспечения понятности во первых принято за
> закрывающей скобкой писать комментарий, к чему она
> относилась, во вторых все современные IDE позволяют быстро
> перейти к парной скобке - посмотреть чего там такое и
> вернуться обратно. Причем делается это горячими клавишами
> за пару секунд.
Правильно, точно так же как все современные IDE от END LOOP позволяют перескочить на начало цикла и обратно. Короче, дело вкуса.
> И т.д.. Сейчас больше не вспомню. Кое какие аргументы
> действительно имеют резон, но БОЛЬШИНСТВО не выдерживают
> критики. Скажем так, я встречал и более качественную
> критику C++, к которой я подкопаться не мог. Точно так же
> как встречал критику паскаля и других виртовских языков.
Это да.
|
| | | | |
Нет, почему же, мне, например, это тоже интересно. Давайте... 16.05.04 15:17
Автор: feldgendler Статус: Незарегистрированный пользователь
|
> > Практически любую задачу,
> > реализованную с помощью виртуальных функций можно
> > переписать на шаблонах и наоборот, но шаблоны совсем
> > не то же самое, что виртуальные функции.
> Ну нет, про виртуальные функции и шаблоны я категорически
> не согласен, но об этом в аську либо в приват, потому что
> это долго :)
Нет, почему же, мне, например, это тоже интересно. Давайте обсудим виртуальные функции и шаблоны?
> > 7) Для меня END LOOP ничуть не более понятен, чем }
> > (если циклов, скажем штуки 4), но при этом набирать его
> > гораздо дольше. Для обеспечения понятности во первых
> > принято за закрывающей скобкой писать комментарий,
> > к чему она относилась, во вторых все современные IDE
> > позволяют быстро перейти к парной скобке - посмотреть
> > чего там такое и вернуться обратно. Причем делается это
> > горячими клавишами за пару секунд.
> Правильно, точно так же как все современные IDE от END LOOP
> позволяют перескочить на начало цикла и обратно. Короче,
> дело вкуса.
Господа, я всё понимаю, но какое отношение имеют эти, чисто косметические, различия к сравнительному анализу языков? Аргументы наподобие "а ещё в паскале оператор присваивания := дурацкий" или "а в C идиотские фигурные скобки вместо нормальных begin ... end" идут в ход на предпоследней стадии holy wars, непосредственно перед переходом на личности и собственно мордобоем.
|
| | | | | |
Если кратко: виртуальные функции обеспечивают полиморфизм времени выполнения, а шаблоны - полиморфизм времени компиляции. 16.05.04 21:51
Автор: Ktirf <Æ Rusakov> Статус: Elderman
|
>
> > > Практически любую задачу,
> > > реализованную с помощью виртуальных функций можно
> > > переписать на шаблонах и наоборот, но шаблоны
> совсем
> > > не то же самое, что виртуальные функции.
>
> > Ну нет, про виртуальные функции и шаблоны я
> категорически
> > не согласен, но об этом в аську либо в приват, потому
> что
> > это долго :)
>
> Нет, почему же, мне, например, это тоже интересно. Давайте
> обсудим виртуальные функции и шаблоны?
Есть подозрение, что это уже интересно только вам :) Так что опять же можно воспользоваться приватом либо аськой либо почтой :) Краткое выражение моей позиции - в сабже.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
