Да полагаю можно просто на листинг посмотреть.

Да там все в порядке Ну можно конечно немного более оптимально написать, но это не ко мне



Конечно, если ограничиться 15ю ферзями, то будет заметно короче (вместо long - short), и быстрее



Листинги в аттаче
Нажмите для просмотра прикрепленного файла

Как там ... "Имеющий глаза, да увидит. Имеющий разум, да поймет"

Ну так уж и быть. Оптимально было бы накодить нечто такое




Листинг в аттаче
Нажмите для просмотра прикрепленного файла

А результат работы АВР как смотреть будем? Так что для корректного сравнения надо еще аналогичный вывод приделать.

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

Угу. printf() использовать для сравнения смешно, прикрутить печать строки и печать числа банально можно, но зачем... Инетесует именно качество компиляции.

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


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


2. На "войне" пора сделать маленький перекур. Предлагаю вниманию всех не_помню_откуда_пришедший дистрибутив Turbo Pascal версии 1.0. Показательно, где мы были в 1983 году и куда мы пришли.


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

-- имеется-ли в Паскале тернарный оператор аналогичный си-шкному

(условие) ? (выражение1) : (варажение2)

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

-- имеется-ли в Паскале возможность использовать макросы типа

(кусок кода взят из реального проекта)

За такой отличный баян - +1000 Даже инсталятор на месте, пришлось ему кнопки подправить под современную клавиатуру. И самое чудное - работает

Ага! Надоело ругаться? А мы Вам щас!...


1. Нет
2. Да (ин-лайн - у Вас опечатка)
3. Нет. Там ведь с макросами всегда туго. В смысле, их нет.

Ругаться? Даже собственно причины нет.

Еще какие-то байки?

Вы опять про Delfi.. или подобные. Паскаль по жизни даже раздельной компиляции не имеет, а тут inline

Ну это вообще не страшно - с легкостью можно воспользоватся сишным препроцессором.

В некоторм смысле -- да. Только не ругаться, а спорить.


Конечно. THX!

Шутка. Была. А Вы ее в тот же унитаз...


Неа. В ТР7, емнип, был квалификатор

Ясное дело, что костыль, но приятно


+1 Так и делал когда-то. Прижало, знаете ли, тоже битики выдергивать. А для масок - можно и константами обойтись. А еще есть оператор with.

а скажите мне, уважаемые Паскалисты, живет-ли еще в Паскале такой анахренизм как множество?

Вопрос вот в чем. Как известно, Си славится тем, что очень компактный. На столько компактный, что не даже имеет встроенных в язык операторов ввода/вывода. Все недостающее обеспечивается библиотеками, который огромное количество. У Паскаля же, на сколько я помню, многие операторы неотъемлемы от языка.

Я помню, что множества можно было объединять, пересекать, еще что-то с ними делать. Помню, что размеры множества не могли быть больше 256 бит. В теории все это выглядело очень красиво. Практически же применить было негде. И я тогда искренне не мог понять -- а зачем они нужны? Разве что только для обучения школьников математике.

Но с другой стороны, опять же было непонятно, операции перемножения матриц в Паскале отсутствуют, действия с комплексными числами -- тоже, а вот множества -- были. Зачем? В моем мозгу это оставило неисгладимый след, как какое-то однобокое (юродивое?) явление в языке. Было крайне не понятно, зачем это в язык встраивать? Сомнительная вещь? -- Оформите в виде библиотеки, кому надо, тот подключит. Зачем ограничили 256-ю битами? А если у меня 365 (по количеству дней в году) единиц будет, что мне делать?

По-моему это был Паскаль от Борланда где-то между 5-ой и 6-й версией. Хотя за давностью лет и абсолютной невостребованностью мозг самочистился от инормационного мусора.

Итак, поддерживает-ли Паскаль множества? Если да, то где сфера их применения?

А у E-LAB оказывается есть версия без ограничений для Mega8/88.
Может кто потестит, а то Огурцов куда-то пропал.
Я не смог заставить работать под wine, а винды нет. Сылка

Ничего не потеряли. Скачал. Поставил. Интерфейс в худших традициях (это когда борланд пытается сделать "красиво" по умолчанию) Ну ладно, потерпим, хотя я обычно сношу такое сразу без дальнейшей траты времени. Будем считать, что кому-то очень нравится. Попытался найти коппилятор командной строки - может и можно как-то делать, но интуитивно непонятно. Зато в всяких проектиков библиотек, утилиток(столь-же жутких с виду) навалено немеряно - все, что надо для бездумного программирования воспитанникам поколения Борланд. Ладно, попытался прицепить вываленное Огурцовым ввиде проекта.... кончилось это PopUp сообщением "internal assembler error 16" и мертвым зависанием всей этой борлондячей красоты. Простите, но на этом я все закончил. Результат компиляции я уже видел ранее. Мне хватило.
Да, кстати, при запуске "это" полезло (пыталось ) на какой-то свой сервак.
P.S.
Да, кстати, если-бы знал, что тот якобы "сишный пример" и картинка запощенная сюда Огурцовым взята с заглавной страницы сайта этой "компании", а не с сайта обдолбанного школяра, то не стал-бы даже ставить этот "продукт", ибо это говорит о его авторах и его качестве все и сразу.

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

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

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

Возьмём русский язык.
1) Переведите английский текст на русский и сравните по длине.
2) Правильность и законченность построения языка.
3) Благозвучность и прочее...

Вопрос.
1)Почему вся конфа здесь на руссом языке?
Ответ.
1) Потому что язык лучше и позволяет лучше выразится.
2) Потому что английский не знаю.
3) Потому что на нём мне общаться комфортнее.
4) Потому что вокруг меня все на нём общаются.

Ответьте саме для себя на эти вопросы и проанализируйте это. Примерно тоже будет и с языками программирования.

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

1) (Почему то никто не отметил, либо я не заметил) Возможность напрямую работать с битами.
Не через and/or а именно на прямую. Объявить UNION, поименовать и вперёд!
2) (Отмечали уже) Построение оператора выбора. Не часто но используется.

Всё остальное - удобство.
1) Лаконичность самого языка.
2) Множественные присваивания
3) Более удобная система работы с указателями.
4) Отсутствие ненужных проверок.
5) Простота операторов.

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

Более грамотное построение локальности/ глобальности переменных. Тут один уже говорил о возможности в Си объявить переменную прямо в цикле. Так вот, видимо он не знает всей правды.

Паскаль имеет иерархическое строение локальности (видимости). Включая процедуры. Схема такая



В месте "*" при вызове D-D. При обращении к i - i2, j-j1
В месте "**" при вызове A - вызовется A2, D-D. При обращении к i - i3, j-j2
В месте "***" при вызове A - вызовется A2, B-B, D-D. При обращении к i - i1, j-j1

Этого в Си не хватает.

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

Я не буду в Си использовать это до тех пор, пока оно не будет поддержано на уровне стандарта.

Блин, я в самых только началах этой прекрасной темы приводил все эти ссылки по AVR паскалю. Все боян.

Совершенно неверная параллель. Язык программирования это не язык Матери, который НЕ выбирают.
Это, как минимум ВТОРОЙ язык. А теперь, давайте ответим на такой вопрос - почему в качестве второго иностранного языка относительно мало распространен не правильно-строгий-простой в освоении Эсперанто а достаточно жутковатый c точки зрения Эсперанто Английский распространен буквально везде.

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

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

Поддерживает. Разбирлся однажды с одним таким исходником - работает. Правда тот кусок переписал и не по причине наличия вложенности, а по причине общей кривизны.

Не думаю, что это будет в стандарте.




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

Ха. Си славится прежде всего тем, что это низкоуровневый язык. Попытка применить его к нестандартной архитектуре, например с троичной системой счисления, или к системе с неограниченной разрядностью обречена на обрастание многочисленными костылями. Как интерпретировать a & b в троичной системе счисления?

Я ж говорю, он мне не понравился. Это не паскаль, это чисто си в его "лучших" традициях.


Вот, у меня других дел нет ?



Принято


Нет, там были другие слова. Два раза.



Может быть. Компилилось примерно так: new project/copy&paste/build all
Изучать возможности компилятора задачей не ставилось.
Не исключено, что таки посмотрю его, но позже.

Хороший вопрос. Ответ на Ваш прос -- естественно под №4.

Аналогия близкая, но, отнюдь, не 100-процентная. Потому как чтобы освоить иностранный язык до такой степени, чтобы можно было на нем хоть как-то разговаривать, нужно потратить как минимум несколько сотен часов. Что бы он стал почти родным нужна одна-две тысячи и более часов. Кто-то тут ранее говорил, что ему достаточно двух дней для того, чтобы выучить новый язык программирования. Разиница между в освоении нового ЯП и нового языка общения -- коллосальна. Согласно этому я утверждаю, что скакать с одного ЯП на другой намного легче, а это значит, что сделать выбор (какой ЯП лучше подходит) намного проще и быстрее, чем тоже самое проделать для языка общения. А это значит, что язык общения он намного сильнее удерживает людей в их социуме, чем ЯП. Т.е. проводить аналогию между ЯП и человеческими языками не совсем корректно.


Примите следующее просто как забавный факт. Недели две назад БиБиСева разглагольствовал по поводу двуязычия у переводчиков. В беседе всплыла одна интересная фича. Вопрос звучал примерно так: "на каком языке у себя в голове вы думаете?" Перводчики, для которых и тот, и другой языки одиноково "родные", утверждают, что когда нужно что-то быстро ответить -- используют в основном английский для построения фразы, когда нужно глубинно помыслить, крепенько-так помозговать -- в основном используют русский.



Ой-ой, уважаемый! Зачем же так -- все в одну кучу?
Одно дело локальные переменные, и совсем другое --вложенные процедуры.
Когда локальных переменных немного и когда применение наглядно -- почему бы не использовать?
А вот от встроенных процедур, я бы держался как можно дальше. С одной стороны -- вроде как экономия памяти, а с другой -- мина замедленного действия в тумане. Рванет хрен знаешь когда. Нафиг-нафиг!



Это... типа... опа! Где эта троичная система применяется в народном хозяйстве? В магазине я видел толко Троичный одеколон. И то лет 15 назад. Что-то я не в курсе, просвятите неуча. А заодно приведите факты, что на троичных вычислителях огромные толпы программистов юзают только Паскаль.

Дак никто не спорит -- Си отлично справляется с низкоуровневыми задачами.


не знаю. А на Паскале это как выглядит?

чем этот "костыль" хуже __attribute__ или #pragma, которыми изобилуют компиляторы С ?
никто не запрещает написать свои функции. например на контроллерах типа АВР накладно использовать многие стандартные библиотечные функции типа printf, приходится писать свои, намного более компактные.

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

почитайте хоть о модулях. и почему расширение С - это нормально (78,83,89,99), а Паскаля (Turbo Pascal, Extended Pascal) - нет ? Может давайте тогда сравнивать версии начала 70х ?
при желании можно добавить все что нужно (локальных переменных и многого другого в первых С тоже не было).

тут описаны некоторые нововведения : http://www.pascal-central.com/extpascal.html. А в том что не развивается дальше имхо виновата непопулярность языка.

Упаси господь !

Да, но никто не пользуется



'Эта фишка' страдает КРАЙНЕЙ неэффективностью реализации. Так же она во многом ограничивает возможности оптимизатора (хотя в Pascal'е этой проблемы нет, ввиду отсуствия оптимизатора ). Для ее эффективной реализации нужна поддержка со стороны аппаратуры. Таковой поддержки нет нигде, а в х86 архитектуре даже были специально сделаны команды enter & leave (в качестве некоторого костыля), которые получились столь ГРОМОЗДКИМИ, что их по назначению не используют даже компиляторы Pascal'я





Потому что расширения С (равно как и он сам) - это СТАНДАРТ, а расширения Паскаля - личные инициативы их расширителей. И если компилятор C заявлен, как отвечающий стандарту C99, то это будет один и тот же язык, какой бы производитель этот компилятор не сделал. Стандарт Паскаля есть (ОЧЕНЬ древний), но компиляторов, его поддерживающих - нет

Я ничего против расширения и развития не имею, только тогда и называйте эти форки соответственно их авторства, а не "Просто Паскаль" и уж тем более отмечая массу реально необходимых для реального использования языка нововедений не спекулируйте на тех красивых, но несовместимых с реальностью постулатах, кои были когда-то заложены Основоположником. Ну и самая основная проблема это абсолютная, в отличии от 'C', хаотичность развития (причем само реальное развитие-то осталось в 80-90x вместе со стандартами) Паскаля. Вот и получаем почти пустой звук при слове Паскаль. Все рассыпалось и продолжает рассыпаться по мелким фирмочкам пытающимся развести пользователей на покупку всяческих "Паскалей" (практически такая-же история и со спекуляцией на слове "Linux"). Паскаль мертв. Давно пора обсуждать из реальных компиляторов тот-же ADA.
Ну соответственно глупые разговоры о Дельфиских наворотах в ветке про программирование AVR.

Хех!

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

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

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

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

Значит можно говорить о том, что Паскаль/Делфи слил позиции низкоуровневого программирования и сосредоточился "ввеху", в области высокоуровневых языков типа Васик, Шарп, С++. Не надо быть гением, что бы увидеть, что и здесь Паскаль/Делфи не имеет особого преимущества перед С/С++. К стати, как нафиг Паскаль для Венды? -- Делфи и толко Делфи! В моем представлении Делфи находится от Паскаля на столько же далеко, на сколько С++ от С.


Я за себя скажу. Для МК я использую чистый С. Для компов использую С++ в купе с MFC. Какое-то время использовал С#, но оставил его, т.к. невозможно объять все сразу. На будущее для себя отметил, что если придется писать только высокоуровневые проги, буду юзать либо C#, либо "неуправляемый"С++. Считаю, что осваивать технику работы с Делфи будет крайне неразумно.

Я затронул этот вопрос не случайно. Во время кризиса можно легко лишиться заказчиков. Возможно придется быстро подбирать то, что будет "пролетать" мимо, т.е. брать работы по созданию программ исключительно для компов. Знание С не даст потонуть ни в области программирования для МК, ни в области программирования компов, чего не скажешь про Паскаль.

Отсюда нелестный вывод про Паскаль -- Паскаль плох своей ограниченностью применения.



Это про множества:

Это понятно. Все правильно! И про С можно сказать то же самое -- "никто не запрещает...".

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


И я про тоже! Если мы вынуждены писать свои функции ввода-вывода, а тем более если у нас вообще не предусмотрен ввод-вывод в контексте readln-writeln (допустим, мы моргаем только ЛЭДами, да собираем цифирь с портов), то становится не понятно, зачем включать в язык эти операторы? На вский случай? Это же избыточность языка.


ЗЫ
Про троичную систему счисления, стёб:
Наверно в этой системе помимо мужской жесткой однозначности да -- это да, нет -- это нет, должна присутствовать женская неоднозначность типа "ни да, ни нет", или "я еще не решила", или даже так -- "догадася сам, почему я на тебя сержусь". Улыбайтесь!

Я вот собсна чего. Прикольная программка получается.
1. Очень облегчает плавный переход от ЦЕ к ПАСу и наоборот.
2. Восстанавливает справедливость в иерархии языков (можете даже обозвать их недоязыками- не обидно нисклько). В том смысле, что ЦЕ - это такой баалшой и умный, но ассемблер. А ПАС все-таки позиционировался как ЯВУ. Да и хрен с ним - пусть этот ЯВУ опирается на ЦЕ, а не на асм.
3. Автор программы, может где-то и прокололся, но, поскольку параллелей между языками очень много, задача практически тривиальная. Это радует. Кто хочет, может ферзей погонять
Такшта, надеюсь примирить всех несогласных...
И студентам кстати будет. И все эти "фичи" E-LAB и прочих дворняжек можно перелопатить и перегнать в ЦЕ. Мир, счастье, лето, трава...

Эх, мыло да мочало - начинай сначала (с)


Си тоже плох своей ограниченностью применения. Однако ж это не мешает вам им пользоваться ?


Так их и нет в микроэлектронике. Да и в дельфи я что-то не припомню, для winapp. В консольных есть, конечно.

Какой там стеб? Суровые начала теории R-функций, например.

Ничего себе утверждение! Трудно сказать что-то более оторванное от практики!
Назовите более широко применяемый язык, чем C/C++!

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

учат теорию (алгоритмику, концепции программирования), я бы начинал изучение с языков типа Python, Ruby, где есть и функциональные элементы, и ООП, интроспекция и т.д.
наверно потому что не знаете Паскаль. Все там есть - и доступ к WinAPI, портам, и встроенный ASM. Можно пользоваться консольным компилятором.
что такое "низкоуровневое программирование" ? еще раз - есть там все для "низкоуровневого программирования".
что за бред, это тот же Паскаль, только расширенный. кстати, Вирт - один из авторов этих расширений http://ru.wikipedia.org/wiki/Object_Pascal , так что можете считать их стандартом. Вы постоянно говорите о каком-то виртуальном "стандартном" Паскале - нет таких компиляторов. А есть реальные компиляторы, напр. http://www.freepascal.org/ - посмотрите, может что-нибудь прояснится.потому что есть мейнстрим, на который работают основная масса разработчиков, ведь был же Борланд, который привел к Паскалю многих людей. Сейчас есть GCC, ICC, MCC, IAR и т.д., которые перетягивают в сторону С. Таково се ля ви, существует куча прекрасных и более продвинутых, но непопулярных языков.

Приближенное к "железу".
Приведите пример драйвера какого-либо устройства, который написан на паскале. Или компилер, рабочий, оптимизирущий, для ARM, AVR или другого контроллера по Вашему выбору.

Что, вокруг один си ? Ну мне даже жаль вас )))


Не так. Нужно вот так: доказать сишникам, что паскаль пригоден в программировании, не удалось.

Хорошая фича:


Нука всмоним, как такое же сделать в GCC ?

Посмотрел генерящийся код - все не так и плохо, оптимизация некоторая проводится. Плюс две дюжины библиотек в комплекте, почти как в дельфи - разные spi, twi, lcs, 1wire, kbd, ps/2, sound, mmc, cf - только садись и пиши.

Как раз наоборот, есть еще дельфи, так что незнание паскаля меня лично несколько напрягает.Да, это так, положительных примеров пока привести не удалось.Это шутка? Так же, через asm (asm volatile).Помотрите еще раз, хотя бы то простейшее выражение "arow[pos + 1] := arow[pos] or place;" и сравните с си: разница реально - в разы.
Там точно нет какой нибудь галочки, "включить оптимизацию"?

Пример, да ?


Не вижу. Все включено(с)

Да пожалуйста!
Преварительно скажу, что писать "lsl" в си вообще нет необходимости, это соответствует "Test_byte <<= 1;", так же нет необходимости писать и "lds", "sts" и явно указывать "r16" - загрузку, сохранение, распределение регистров компилятор осуществляет самостоятельно. Т.е., где Test_byte - глобальная переменная, компилятор преобразует вНапомню, что "lsl" - синоним "add rX, rX", в случае регистровой переменной "lds", "sts" просто не будет.
Если у Вас есть еще неясности по поводу AVR-ассемблера в gcc - рекомендую GCC-AVR Inline Assembler CookbookНу что же, значит паскаль реально не пригоден для программирования AVR.

знаю что не по теме, но душу греет



автор kochetkov.vladimir
http://www.rsdn.ru/Forum/message/3215532.aspx

C детства программирую на паскале. А для PC - только на паскале.
И вот пришлось освоить Си.
И что интересно. Двоеточие после равно я ставить отучился, а ставить двойное равно - нет.

И еще количество круглых скобок в Си напрягает. Просто безумие какое-то. Либо постоянно иметь ввиду очень странное старшинство операций. Либо скобки изо всех сил ставить.
if (B==A&3) чисто понятно чего я хочу, а работать не будет.
В итоге if (B==(A&3)) ... Уж лучше бегин энд, чем лазить с шифтом наверх клавы постоянно.

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

Если постоянно путаете = и ==, заведите привычку писать не i == 0, а 0 == i - тогда будет ошибка при просто =.

Детские болезни.
Не стоить так беспокоиться, с возрастом обычно они у многих проходят. Не у всех, правда. Не все люди одинаковые. Многие так и остаются в розовом детстве.
Взрослейте и будем счастье!


Ага. Это правда. И я видел как один художник рисовывал картину на стене (своего) гаража. А когда приперло быстро подготовить еще одну стену, он тупо взял валик и ведро грунтовки. Не едкие замечания не реагировал. Собака!

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

Какие проблемы? А может просто "Вы их не умеете готовить?" (С)

Ну и только честно, нафига было в Паскале делать =: для присвоения , как наиболее частой и к тому же естественной "привычной с детства" арифметической операции а зато односимвольную и более редкую = валить в одну кучу со всякими <>. Ответ такой-же, как и данный ниже - для рекламных целей - за 15 обзорки рисовалась на доске некая хрень в которой НИЧЕГО не вычислялось, зато псевдоанглийский if else then end пару названий переменных цифр и if A = B присутствовали, ибо рассказывали не как вычислять - калькулятором не удивишь. При таком галопе объяснения разницы между = и =: было лишним .

Большинство массовых приоритетов покрываются "естественными". А кроме того, наличие большого количества мнгоуровневых приоритетов по сравнению с ОТСУТСТВИЕМ может ухуждшить ну разве только чтение лицом их незнающим, но никак не НАПИСАНИЕ - количестово скобок, как привычно, а отнюдь не "изо всех сил ставить".

Абсолютно не верю, при наличии аналогичной мути для изготовления уродцев - Builder, да и MVC вполне бездумно и быстро слепить позволяет....

Увы, это хоть и избитый повод для разговоров, но эти два слова полный бред созданный исключительно из-за вешания лапши на уши - смотрите это на английском написано! Какой прелесный "понятный" язык! В общем для 15 минутной лекции перед "домохозяйками" (к коим в 60x относились почти все ) очень хороший ход. Для удобства компилятора - явные длинные ключевые слова. Но никак не для удобства реальных людей, ибо всякие скобки во всех применениях служили и служат человечеству ровно для той-же цели - выделения некоего блока.

При все уважении, не могу согласится.

Как минимум у меня это в VS легко и быстро не получается.
Все зависит от "тяжести" создаваемой проги.

Не, я конечно тоже могу за полддня слепить что-то типа AVR-килькулятора или за 5 минут "Драствуймир" или за полчаса решение квадратного уравнения с прибамбасами. Но когда дело касается како-то мощной системы (например, како-нибудь навороченный анализатор входных сигналов, получаемых с объекта через USB или TCP/IP), то сначала обдумывается архитектура, обдумываются классы/объекты; кто с кем и как будет взаимодействовать, кто на кого будет влиять; какие будут результаты, куда и как их будем писать; что будет делать прога в тех или иных случаях, что будет видеть юзер, в какие моменты подновлять фэйс проги, сколько потоков и когда создавать и т.д. и т.п.

Т.е при всем желании, если ничего этого в голове нет, писать код толку мало -- VS все равно не даст продвинутся дальше интефейса. Зато когда это все в голове устаканится, код пишется легко и быстро. Непринужденно.

Помятуя свой прошлый опыт Делфей (и аналогично -- Вижуал-Васика), утверждаю, что в этих средах/языках существует очень большой соблазн начать проект сразу, с горяча. С того, что на форму накидываются компонеты и затем их не задумываясь соединяют. Простые проги так можно создавать. У больших проектов при таком безбашенном подходе после какого-то времени разработки/развития начинают вылезать сначала мелкие нестыковочки, потом больше и больше, и т.д. по экспоненте. Потом начинаешь понимать, что основная масса времени идет не на создание продукта, а борьбу с окучиванием компонет, которых поначалу накидал не думая, соблазнившись RIDical perfomance © Borland.

Т.е. что я хочу сказать. Я хочу сказать, если предстоит построить быстро небольшой проектик (само собой -- некоммерческий!), можно взять то, что позволяет быстро сделать тяп-ляп и как-получится, не взирая ни на объемы ехе-шника, ни на скорость исполнения, ни на возможные падения ("Программа совершила недопустимую операцию и будет..."). Но если стоит задача получить на рынке денег за продукт, и не опарофиниться перед клиентом после поставки, то Делфийская Рэпид-технология отдыхает на Канарах.

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

Обдумывание архитектуры и отладка занимают на порядок больше времени, чем расстановка компонет на форме и их логическое связывание. Когда знаешь что делать, текст проги набрать не долго. Если уж так надо экономить время то, наверно это делать надо не тех операциях, которые и так не имеют большого веса (времени). Конечно, если "программист" испытывает проблемы при наборе текста программы... , не знает клавиатуру... то, да-а. Тут можно и нужно использовать Рэпид-инструменты. Как правило, такие "программисты" и не создают сложных программ.

Пластилиновый софт создается быстро. Но ... пластилин, он и есть пластилин!

PS
Только что пришло письмо с books.ru.

Никогда не задумывался на тему, что "свои" книжки я покупаю так дорого:
* Макконнелл "Совершенный код" -- 803 рубля
* Руссинович, Соломон "Внутреннее устройство Венды" -- примерно 1000 (мне достался бесплатно, из "Боекомплекта разработчика")
* Рихтер "Windows via C/C++" -- 1245 рублей,
* Бовет "Ядро Linux" -- 680 рябчиков,
ну и т.д. У многих они есть. Не в этом дело.

Я сходил по предложенной в письме ссылке. И там мне предлагают тако-ое..., ну тако-ое... =8-0
http://www.books.ru/shop/books/717
Это ж как надо было опустить продукт! Что если еще чуть дешевле, то уже только даром!

Дайте две!

хм, получается что в VS мозги работают, а в Delphi - отключаются ?
как раз возможность набросать за полчаса 10 вариантов GUI и выбрать подходящий - очень болшой +.

Ну не знаю, знак присвоения := мне казался абсолютно логичным (кстати, именно так, а не =: )
Более того, на этапе ассемлера 8080 этот же знак использовался в блок-схемах алгоритмов.
Наверняка из какого-то старинного идет.
А != ну явный бред! Я до сих пор чаще использую !( a==B ). И то более логично получается.

Конечно плюс. А разве это всегда самое главное?

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

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

Ух, я когда-то еще с Turbo Vision... В общем объект TEditor, для неокрепших умов - куча кода, хз как работает. Что-то более-менее добавить из функционала - невозможно. Проще с нуля переписать самостоятельно. При попытке красивого расширения наталкиваешься на специально заложенные грабельки, для "сдерживания роста юзера" - это не просто числа вместо констант, или какие-то упрощения, шитые белыми нитками - это нерасширяемая и глубоко продуманная концепция. Поэтому или прогер учится создавать свои компоненты, или борется с абстиненцией при недостатке борландячих - существенно расширить их не удастся.

Суровые парни вообще не заморачиваются интерфейсом. Все идет через командную строку

Ужасно!!!
Как же у людей мозги "испорчены" этим паскалем!

Вы знаете, у меня все тоже самое, но с точностью до наоборот!
Прывычка -- очень серьезное дело.

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

Я легко выцепляю в "овсянке" кодов комбинации символов !=, ->, ::, { }, null. И меня также цепляют заусенки типа BEGIN-END-FUNCTION-PROCEDURE, :=, NOT, nill. Но это ничего не значит.

Кому-то без разницы -- как классифицируется блок кода, а кто-то заостряетсвое внимание и говорит, что это есть очень большая, т.е. _принципиальная_ разница: процедура это или функция. На столько большая, что это надо особо выделять. И выделяют. И ничего, живут.

Это не бред. Это -- религия!