Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
>Процесс разработки ПО и ЯП 04.05.04 12:44 Число просмотров: 3186
Автор: 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% является крайне значимой.
В общем как уже сказал кто-то до меня - можно привести кучу подобных аргументов против Вирта. И правда напоминаете студента почему-то обидевшегося на С++.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
