Всё непонятное - магия. 
Или религия.

Я даже так делал в инсте. От замены нескольких слов суть языка не поменяется, и дырки в нем не исчезнут. Хотя я сейчас вообще подумываю над фактически иероглифическим языком, который описывался бы более крупными программными единицами, вроде "объявление типа", "объявление функции", "оператор присваивания", а уж среда сама могла показать это в стиле любого выбранного языка. Для .NET ИМХО вполне реализуемо для шарпа, VB.NET и Oxygene, да и Фортран явно подойдет.



Боюсь, что мои шансы получить сложное приложение даже несколько повыше, чем для тебя, т. к. я за нефиг делать могу упереться в объем данных, которыми десктопщики обычно не оперируют, да и база для форума, ну вроде винграда, мелкой покажется. Хотя для разморозки интерфейса действительно может быть достаточно даже Application.ProcessMessages.



Еще раз. Весь необходимый для работы языковой функционал в Delphi давно уже есть. Не переоценивай отдельные фичи шарпа. И кстати, а в других языках эти фичи есть? А то Delphi, как язык сейчас, похоже, мощнее жабы, и, возможно, даже плюсов. По крайней мере, плюсам не уступает, это 100%. Про жабистов ты сам говорил, что им опиши шарп, а они в ответ: "нам это не надо". Может действительно не надо?



Видимо мы понимаем разные вещи под "рулили". .NET 2.0 была неюзебельна и это медицинский факт, подтвержденный контактами с реальными приложениями на нем.



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



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



Учить новое, только потому что новое? Ну не знаю. Потыкаться и почитать о возможностях за учить не считаю. Проблемы надо решать по мере их возникновения. Впрочем ты так и не понял ни хрена. Запусти Builder XE3. Видишь, там есть подсветка соответствующих фигурных скобок. В Delphi аналога нету, я не скажу, что он совсем не нужен, но в целом проблема выделения начала и конца функциональных блоков в Паскале куда менее актуальна. Так что обилии тулзов может говорить и об обилии проблем.



У меня override есть.



У меня таких частных примеров тут для статистики вполне достаточно.



Я буду спрашивать, как юзать дженерики, или переходить с 2007 на юникод, когда все, кому не лень уже сделали обзоры? Да и литература уже имеется.



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

@Zloxa


Если нужны реальные примеры, то идём и находим реальную библиотеку с реальными примерами.

Например, пишу я YaLinqo -- LINQ to Objects для PHP. Каждый метод я покрывают тестами, чтобы быть уверенным, что они работают верно при всех входных данных: сколько и какие аргументы переданы, какие используются по умолчанию; что нормально обрабатываются случаи типа пустых коллекций или повторяющихся элементов; что выборка работает верно на разных типах данных; что при неверных аргументах выпадают корректные ошибки и т.п. На каждый метод пишутся десятки тестов (в самой библиотеке похожие тесты "упакованы" в один, что не совсем труЪ, но мне лень писать лишний код), покрывающие как основные случаи, так и граничные. Также покрываются тестами все вспомогательные классы: специфические коллекции, парсинг лямбд и т.п.

Даже во время написания тестов часто обнаруживаются ошибки, которые сразу же на месте исправляются. Чтобы проверить то же самое без тестов, нужно огромное количество времени, баг-репорты со стороны и прочее (очевидно, я сам не пользуюсь всеми фичами библиотеки на 100%, а если пользуюсь, то граничные случаи довольно редки). Без тестов написание подобной библиотеки на достойном уровне практически невозможно.

Теперь выходит PHP 5.5, в нём есть долгожданные yield return/break. Написание итераторов слезает с велосипедов и полностью переписывается на новые конструкции. Код становится более читаемым и горазло более быстрым. Всё зашибись. Но меняются только внутренности (реализация), внешне (интерфейс) библиотека остаётся прежней. Она должна продолжать корректно обрабатывать всё те же самые случаи, те же самые аргументы, те же самые коллекции.

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

Обращу внимание: разработчик у библиотеки ровно один, я сам. Покрытие тестами практически 100%.

 
Можно взять другой пример -- FluentMigrator -- миграции БД с fluent синтаксисом. Там есть юнит-тесты, которые проверяют корректность построения выражений. Там есть интеграционные тесты, которые проверят работу миграций на разнообразных СУБД. Разработчиков много, регулярно принимаются пулл-реквесты (патчи) со стороны. Если кто-то что-то добавляет, изменяет, то тесты гарантируют, что уже реализованные фичи внезапно не отвалятся.
 

Ну и абстрактный пример. Пусть есть функция Foo, которая используется по всему проекту. Внезапно обнаруживается, что из-за неправильности её работы в функции Bar получается неверный результат. Функцию Foo исправляют, функция Bar теперь хорошо работает, в чём можно убедиться, хотя бы погоняв программу в рантайме. Но вот кто гарантирует, что исправление функции Foo не сказалось в других точках системы? Заново вручную тестировать всё приложение из-за исправления одной строчки вряд ли кто-то возьмётся. И в результате окажется, что где-то "неправильный" результат Foo очень даже помогал, и что-то поломалось. Что поможит отследить подобные случаи?

Тесты.

P.S. Я не сторонник "идеально чистых" тестов, когда реальный класс тестируется только один, а абсолютно всё вокруг -- моки (mocks) и стабы (stubs). Стараюсь использовать только реальные классы, пока это возможно и оправданно, даже если "юнит-тесты" из-за этого морфируют в интеграционные тесты.

P.P.S. Догматичное TDD -- по-моему, фантастика. Применение возможно, но весьма ограничено.

Athari, спасибо большое. Чуть позднее, за чашечкой чая, обязательно перечитаю твой пост более внимательно.

PS. Привет, Athari
Надеюсь тебе здесь понравится

@Zloxa

Спасибо за приветствие, но я вряд ли тут надолго (как и в любом другом месте). Я вообще существо необщительное. 

@Beltar


Генерация заготовок классов по UML? Это как бы уже придумали.


Сложное = сложная логика (тысяча классов предметной области, например). А у тебя из сложности -- только объём данных (миллион строчек в одной таблице БД на несколько гигов). Почувствуй разницу.


Необходимый тебе.


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


Почитай список фич С++11 и посмотри, сколько из этого есть в дельфи. Подсказка: примерно ноль.

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


Среди жабистов много тех, кто с этой идеологией несогласен. Но выбора-то нет.


Чьими контактами? Твоими аж двумя? Давай не разбрасывайся липовыми фактами, а скажи по делу, что именно было не так в .NET 2.


Уточним: глюкалово встроенного визуального дизайнера при использовании нестандартных приёмов. Для тебя это почему-то эквивалентно глюкалову всего WPF. Красиво обобщаешь.


Так-так-так, уже концепция неправильная. Итак, что неверно в концепции WPF?


Собственно, дельфи. Что и требовалось доказать.

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


Потому что полезное. LINQ, WPF, WCF, Rx -- я всё это успешно использую и очень доволен. Подробное изучение начинается после того, как ты о чём-то узнаёшь. Но ты даже слышать о чём-то новом не хочешь. Я только и слышу: "Мне не нужно!"

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


Добавляется плагинами.


Я про вызов метода. Когда вызываешь, видно, что этот метод статический. То же с полями.


Понял. В твоём присутствии шутить противопоказано.

Если что, я изучал "врагов" WPF в мире плюсов (Qt), в мире джавы (JavaFX), теперь в мире дельфи (FireMonkey). Я изучал "вражеские" языки, чтобы научиться чему-то новому. Но вот почему-то в случае дельфи мне ничему новому научиться не удалось. К чему бы это...

Да что вообще можно говорить о дизайне языка, у которого все объекты только в куче, а сборки мусора нет? Про синтаксис вообще молчу - выразительность очень низкая, всё описывается огромным количеством букв. А читать это без подсветки - практически нереально.

@Bother


Записи (records) в стеке же.


Странная метрика. Мне практически никогда не приходится читать код без подсветки. Зачем это?

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

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

@Bother


Делает утверждение "все объекты только в куче" неверным.


Дома есть ИДЕ, на работе есть ИДЕ. На каком компьютере без ИДЕ надо программировать? У клиента? Код дельфи у клиента даже скомпилировать толком не выйдет (даже если код притащить с собой).

Я понимал бы аргумент, если бы речь шла об администрировании, и на компьютере были только bash/powershell и голая командная строка -- да, читаемость без подсветки будет важна. Но дельфи-то тут при чём? Что за безИДЕшная ситуация такая?

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

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

Ну переопределяй InitInstance, в стеке рекорды по-любому. А еще и object'ы. Сразу видно эксперда. GC в Паскале если и нужен, то ну в Обероне он есть, а так, нафига он?? Чтобы Free не писать?



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



Это твои проблемы.



А мне приходилось. С бумаги. Распечатки сишных листингов в книгах, это больно... Как я любил в такие моменты и begin, и end, и then, и procedure, и function, и все остальные жирные ключевые слова...



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



Для тупых объясняю, Delphi Prism это компилятор Oxygen воткнутый в IDE от VS или Mono. Там от Абракадабры одно название. В случае фоно проект зафейлился для обоих языков. Создал GTk-проект, нажал запуск, долго ржал над фейлом. Потом оказалось, что она у меня еще и оперативку всю сожрала.



Ну слава богу, ты хоть до этого допетрил. Теперь осталось только допетрить до того, что дельфины со своей стороны никого не учат, как им жить и на чем писать. Вот не будет необходимого мне функционала, поищу инструмент, но сейчас я не представляю ни одной задачи которой мне бы пришло в голову заняться, которую нельзя было бы сделать на Delphi. Кстати, оказывается психи, пишущие коммерческие игры на Delphi\Builder'е до сих по не перевелись. Попался вот один образчик.



Спасибо, но я над ними уже поржал. Верной дорогой крестики топают...



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



Ты не понял этого за 10 лет? Кстати, как раз в мае юбилей будет.   



LINQ мне нужно, ну или, по крайней мере, хуже точно не будет. Но и чудес я от него не жду.

Это сообщение отредактировал(а) Beltar - 25.4.2013, 18:08

Т.е там 2 объектные системы? Ещё хуже. Привет структурам в диезе.
можешь оставить свои фантазии - никто про компиляцию или работу без ИДЕ не говорил. Я лишь констатировал факт плохой читаемости, а то что ты дальше напридумал мне не интересно.

Добавлено через 8 минут и 27 секунд
причём здесь рекорды? Или ты думаешь я буду переписывать под них сторонние классы? А гц в такой ситуации просто необходим. 
функциональщина легко читается. А весь мир, использующий сишный синтаксис, согласен что гораздо легче воспринимать выделяющиеся в тексте элементы(фигурные скобки), нежели смешанные с тестом слова. Да и разное убожество вроде объявления переменных в начале на пользу не идут(только путают, да текст лишний генерируют).

Учи матчасть и не канифоль мозги.

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