Чем вам не нравится Delphi?

[Stilet]

нечувствительность к регистру

Ниче себе минус... Это плюс, причем весьма большой.

нет перегрузки операторов

К черту.

одиночный уровень включения uses

Что имеется ввиду?

[profi]

Ниче себе минус... Это плюс, причем весьма большой.

Потом людям сложно переходить например на С++ или Java. А потом появляются такие темы: http://www.programmersforum.ru/showthread.php?t=94911

[Stilet]

А потом появляются такие темы

Такие темы появляются по невнимательности. Мне например совсем не нравится что в Си и в Обероне регистрозависимость. Мне неудобно постоянно шифт жать.

[Arigato]

Сообщение от docbrain

Ну, такого нет, по-моему, только в Бейсиках. Да и то, в самых примитивных.

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

Сообщение от profi

Потом людям сложно переходить например на С++ или Java.

Ну так это не минус Делфи в том, что людям с него сложно переходить на С++ или Java. Это минус С++ и Java, что они чувствительны к регистру.
Вообще, из-за подобной неразберихи с чувствительностями к регистру я уже давно выработал у себя стиль всегда придерживаться одного регистра во всех идентификаторах, причём делаю это и в Делфи.

[pu4koff]

Сообщение от Utkin

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

Не обязательно, но удобно. Создали мы класс матрицы и нужно нам их 4 штуки перемножить. Придётся выстраивать что-то такое:
e := a.Mul(b.Mul(c.Mul(d)));
а так бы написали:
e := a * b * c * d;
Меньше писанины и лучше читаемость. Я не считаю это сахаром, ибо никакой новый синтаксис для этого вводить не нужно. Умножение оно и так для простых типов есть.

Сообщение от Utkin

И где здесь минус?

Регистронезависимость - это минус.
1) Один и тот же код может выглядеть иначе
2) Придется приставки добавлять к именам членов классов, параметров методов,...
На С# я бы написал:

class A
{
  private int _param;

  void A(int param)
  {
    _param = param;
  }

  public int Param
  {
    get { return _param; }
    set { _param = value; }
  }
}

И сразу видно, что _param - это приватный член, Param - свойство, а param - параметр конструктора. По крайней мере для меня это удобно.
На делфи пришлось бы написать:

class A
private
  FParam: integer;
private
  function GetParam: integer;
  procedure SetParam(NewParam: integer);
public
  constructor Create(AParam: integer);
published
  property Param: integer read GetParam write SetParam;
end;

Не сильно напрягает, но писанины больше и визуально не так хорошо выделяется. А имена типа: FField, AArc и т.п. банально некрасиво выглядят и плохо читаются. Еще к минусам бы добавил реализацию свойств. Синтаксис не самый удачный. НА C# он в разы короче и удобнее.

Сообщение от Utkin

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

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

Сообщение от Utkin

На фига козе баян?

При выделении памяти на стеке, можно не переживать об её освобождении. Создание объекта на стеке является в этом плане безопасной операцией. Не нужно следить, что где-то вылетит исключение и в итоге что-то где-то потеряется. Ну и в качестве бонуса: выше скорость работы с объектом.

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

Сообщение от Utkin

Это полезно - дисциплинирует

Я бы не назвал это полезным. Это просто другой способ со своими плюсами и минусами. В больших функциях будет длинный список описания переменных, в котором бОльшая часть будет типа i,j,k,... для реализации циклов и подобные вспомогательные переменные. В С++ же написал:

for (int i = 0; i < 10; ++i)
{
...
}

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

[Arigato]

Сообщение от pu4koff

Регистронезависимость - это минус.

По мне, так минус - это когда в одном и том же коде будут переменные a и A или temp и Temp. Путаницы куда больше.
С Вашим примером не понял, почему в одном случае NewParam, а в другом AParam, ничего не мешало везде использовать Param, а в private назвать _param, что и было у Вас сделано с сишном коде, так что пример очень натянутый, показывающий лишь то, что можно написать подобную чепуху, но лучше так не писать.

[Stilet]

мда... Развел вас, ребята, тролль...

[pu4koff]

Сообщение от Arigato

По мне, так минус - это когда в одном и том же коде будут переменные a и A или temp и Temp. Путаницы куда больше.
С Вашим примером не понял, почему в одном случае NewParam, а в другом AParam, ничего не мешало везде использовать Param, а в private назвать _param, что и было у Вас сделано с сишном коде, так что пример очень натянутый, показывающий лишь то, что можно написать подобную чепуху, но лучше так не писать.

Так лучше?

class A
private
  _param: integer;
private
  function GetParam: integer;
  procedure SetParam(AParam: integer);
public
  constructor Create(AParam: integer);
published
  property Param: integer read GetParam write SetParam;
end;

В предыдущем посте написал чуть иначе, т.к. не принято в делфях называть члены с подчеркиванием, а используется именно приставка F.
Мне лично не нравится, что в одном месте напишут MainForm, в другом mainform, а в третьем могут вообще написать MaInFoRm. Я, в любом случае, на делфях всегда старался писать везде одинаково для последующего удобства чтения. Да и большинство программистов пишут имена переменных/классов/функций/.. везде одинаково, т.е. регистронезависимость приводит только к тому, что нельзя в одной области видимости создать переменные Temp и temp. Вот собственно и всё. Кроме того это приводит к невозможности создания переменной customer: Customer. Мелочь, а лично мне неприятно. Да я знаю, что так переменные называть не айс, но мне лень на каждый чих придумывать осмысленные имена.

[Utkin]

Сообщение от pu4koff

Не обязательно, но удобно. Создали мы класс матрицы и нужно нам их 4 штуки перемножить. Придётся выстраивать что-то такое:
e := a.Mul(b.Mul(c.Mul(d)));
а так бы написали:
e := a * b * c * d;
Меньше писанины и лучше читаемость. Я не считаю это сахаром, ибо никакой новый синтаксис для этого вводить не нужно. Умножение оно и так для простых типов есть.

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

Регистронезависимость - это минус.
1) Один и тот же код может выглядеть иначе

Он может выглядеть иначе и в регистрозависимом коде.

2) Придется приставки добавлять к именам членов классов, параметров методов,...
На С# я бы написал:

class A
{
  private int _param;

  void A(int param)
  {
    _param = param;
  }

  public int Param
  {
    get { return _param; }
    set { _param = value; }
  }
}

И сразу видно, что _param - это приватный член, Param - свойство, а param - параметр конструктора. По крайней мере для меня это удобно.

В edn об этом прямо и заявлено - имена должны иметь приставки. Если уже совсем тяжко, можно написать вложенный класс, или объявить вложенную структуру.

На делфи пришлось бы написать:

class A
private
  FParam: integer;
private
  function GetParam: integer;
  procedure SetParam(NewParam: integer);
public
  constructor Create(AParam: integer);
published
  property Param: integer read GetParam write SetParam;
end;

Не сильно напрягает, но писанины больше и визуально не так хорошо выделяется. А имена типа: FField, AArc и т.п. банально некрасиво выглядят и плохо читаются. Еще к минусам бы добавил реализацию свойств. Синтаксис не самый удачный. НА C# он в разы короче и удобнее.

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

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

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

При выделении памяти на стеке, можно не переживать об её освобождении. Создание объекта на стеке является в этом плане безопасной операцией. Не нужно следить, что где-то вылетит исключение и в итоге что-то где-то потеряется. Ну и в качестве бонуса: выше скорость работы с объектом.

а) Я считаю, что здесь должна быть китайская философия - во всем должно быть равновесие - "наксерачил? убери за собой!" Причем сам.
б) Можно отказаться от ООП - скорость будет еще выше.

for (int i = 0; i < 10; ++i)
{
...
}

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

Ну это тоже не минус. И потом больших функций быть не должно. Максимум 2-3 экрана.

Мне лично не нравится, что в одном месте напишут MainForm, в другом mainform, а в третьем могут вообще написать MaInFoRm. Я, в любом случае, на делфях всегда старался писать везде одинаково для последующего удобства чтения.

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

[pu4koff]

Сообщение от Utkin

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

Это понятно, что идиот какой-нибудь может посредством этой операции суммировать матрицы, а не умножать, но так можно намудрить с чем угодно. Можно и в функции Sum перемножать.

Сообщение от Utkin

В edn об этом прямо и заявлено - имена должны иметь приставки. Если уже совсем тяжко, можно написать вложенный класс, или объявить вложенную структуру.

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

Сообщение от Utkin

Это хорошо когда писанины больше - чтобы программы писали не по-быстрому, а с пониманием, того, что программист в данный момент делает.

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

Сообщение от Utkin

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

Это понятно всё. Я и не говорю, что делфи - это бяка такая уж. У неё есть недостатки, как и у всех других языков. Тут главное до фанатизма дело не доводить, а то получится, что глюки компилятора тоже плюсами окажется, т.к. будут способствовать развитию программиста в направлении ассемблера.

Сообщение от Utkin

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

Можно левое ухо правой пяткой чесать, но зачем? Мне читать код на С++ или шарпе ни капли не сложнее, чем на делфях. Некоторые моменты благодаря синтаксису понятнее получаются, некоторые - наоборот. Я не хочу писать лишние буквы или заморачиваться с автозаполнением, т.к. мне более длинный синтаксис не даёт ровным счетом ничего. Кому он приятнее глазу - пусть пишет на здоровье, а для меня большая часть синтаксиса делфей является минусом.

Сообщение от Utkin

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

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

Сообщение от Utkin

а) Я считаю, что здесь должна быть китайская философия - во всем должно быть равновесие - "наксерачил? убери за собой!" Причем сам.

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

Сообщение от Utkin

б) Можно отказаться от ООП - скорость будет еще выше.

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

Сообщение от Utkin

Ну это тоже не минус. И потом больших функций быть не должно. Максимум 2-3 экрана.

Можно нафантазировать сейчас кучу возможных проблем, появившихся из-за описания переменных в начале. Я не пытаюсь "опустить" делфи, поэтому фантазировать не буду. Да это мелочь, да она особо ни на что не влиеят, но черт возьми мне это неудобно. Поэтому для меня это минус.
Кстати, есть ли в новых версиях делфей циклы по типу foreach или до сих пор не прикрутили такую полезность?

Сообщение от Utkin

А почему? Потому что Вы категории одного языка переносите на другой. В Дельфи тоже есть определенные правила оформления кода.

Я бы не стал такую мелочь приписывать к особенностям языка и т.п. Ну какие правила, если я могу банально опечататься и написать mAinForm. Мелочь, ничего особенного, но некрасиво. Почему было не сделать зависимость от регистра, чтобы MainForm так и был везде именно с таким набором символов? Запретить объявлять mainform, когда в области видимости есть MainForm - так же не проблема.
По сути в языке нет никаких серьезных недостатков для меня, но вся вот такая мелочь в итоге собирается в кучу и получается, что другой язык больше нравится, нежели делфя. Собственно и тема не претендует на объективность. Моё субъективное мнение такое.