Какой ЯП более гибкий.

[VSL]

Ничего странного - БД это прежде всего корпоративный сектор, а OpenSource (массовый)

А вот это? http://www.sogo.nu/english.html или есть еще Zimba. Хотя я сам точно не знаю, поскольку не используем.

[tema]

Ух... Ёпрст... Как-то мимо меня прошло, что тема получила продолжение
Я так понимаю, что для моих оппонентов мне нужно было специально заготовить табличку "сарказм" (с) TBBT
И теперь только вижу насколько вброс-таки удался
Хотя я на самой первой странице ещё предложил признать это троллингом.

Добавлено спустя 13 минут 3 секунды:

Синтаксический сахар нельзя забывать, например функция возвращает перечисляемый объект и этот результат мы раскидываем по переменным, затем делаем цикл с автоматическим целочисленным индексом:

Код: Выделить всё

def myfunc():
    return 'qwe'

a, b, c = myfunc()

for i, v in enumerate(myfunc()):
    print '%d:%s'%(i, v)  # 0:q 1:w 2:e


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

..bw

Код: Выделить всё

var
a:char;
s:string;
function myfunc:string;
begin
  myfunc:='qwe';
end;

begin
  s:=myfunc;
  for a in myfunc do
    writeln(a);
end.


Не намного больше. Это я привёл пример с использованием in, чтобы показать что можно сделать почти так же соответсвующую строку Вашего кода. Правда, для вывода счётчика нужна будет ещё переменная, но тут можно классикой:

Код: Выделить всё

var
s:string;
i:integer;

function myfunc:string;
begin
  myfunc:='qwe';
end;

begin
  s:=myfunc;
  for i:=1 to length(s) do
    writeln(i,':',s[i]);
end.


Количество строк не изменилось

[VSL]

А кстати, freepascal (ну или просто паскаль) это ООП язык или нет?

[Mr.Smart]

VSL http://ru.wikipedia.org/wiki/Pascal#.D0.A1.D1.82.D0.B0.D0.BD.D0.B4.D0.B0.D1.80.D1.82.D1.8B

[Ism]

Лучше спросить так , Какой член более гибкий ?
Ну это смотря для какой женщины

[hinst]

вот взять хотя бы наличие таких типов как class и object. Очень гибко. Можно использовать class для всяческих классов общего назначения типа окон или файлов, которые хранятся в куче. А object для всяческих штук, которые должны работать быстро и храниться в стеке. Типа координат трёхмерных точек или там я не знаю чего. А в этой вашей Java, например, так нельзя. Там все классы в куче. Или взять, к примеру, C++. Там, вроде бы, можно любой класс сделать как в куче, так и в стеке. Но в паскале object отличается от class ещё и тем, что он, насколько я знаю, привносит с собой меньше дополнительных действий, необходимых для его работы. В общем, долго объяснять.

Мало того, что во фрипаскале есть class и object, там есть ещё и interface. Им можно делать объекты, которые уничтожают сами себя как только становятся не нужны. Очень гибко и удобно. А в этой вашей жабе так нельзя. Там все объекты уничтожаются фиг-знает-когда.

Итак, в паскале я могу использовать:
CLASS: чтобы делать классы общего назначения с ручным удалением
COMPONENT: чтобы делать классы, которые удаляются, когда умирает родительский объект. Очень удобно. Когда компонент-окно, например, удаляется, то все его компоненты-кнопки и прочие тоже удаляются
INTERFACE: чтобы делать классы с автоматическим удалением. Причём, не во время какой-то там сборки мусора, а сразу как только они становятся не нужны.
и, наконец, OBJECT: чтобы делать объекты, которые должны работать очень быстро, без всякого мусора и дополнительной нагрузки, и, к тому же, иметь возможность размещаться в стеке.

Так что... гибкость налицо, товарищи. в C++ тоже так можно, но в паскале это всё сделано практически почти что на уровне языка. Тогда как в C++ такое сделать можно только с помощью хитроумных библиотек, с которыми, насколько я знаю, работать не очень-то приятно. Да и типа TClass там нет. То есть, фактически, тип я передать в качестве параметра, как таковой, не могу. Опять же, TClass поддерживается на уровне языка. И сказать: "создай мне объект такого-то определённого заранее не известного типа, который мне передастся" на паскале очень легко. Чего не скажешь о C++. Да и в других языках с этим проблемы.

Отдельно скажу про наличие полноценных виртуальных конструкторов. Или нет, не скажу... Тут уже мне лень пояснять... устал. Кто знает, тот поймёт. И виртуальные статические методы в паскале тоже предоставляют дополнительную гибкость. Хотя, я сам ими не пользовался, не скажу наверняка, запилены ли они во фрипаскале по-нормальному. А в этих ваших C-подобных языках все конструкторы при наследовании становятся protected (в некоторых случаях, мда.). И это не добавляет им гибкости!

[SSerge]

от взять хотя бы наличие таких типов как class и object. Очень гибко.

А ничего, что они относятся к разным категориям поддерживаемых языков и совместно их использовать нельзя? Причем, появились по чисто исторической причине - сначала был object, экземпляры которого многие стали размещать статически и громко жаловаться на непредсказуемое поведение программы (стек TP по умолчанию 4К, если не забыли (если знали, конечно ), причем в руководстве программиста было прямо сказано - следует избегать статических экземпляров объектов. Ну кто же читает документацию то? Ну, и далее кто то заметил, что получается слишком много указателей, и тексты прямо пестрят значками "^", что отрицательно сказывается на читаемости и приводит к частым пропускам этого знака в наборе. Вот и появился class, где все экземпляры только динамические и любая переменная представляет собой указатель.

там есть ещё и interface. Им можно делать объекты, которые уничтожают сами себя как только становятся не нужны. Очень гибко и удобно.

Вы про что это? Про тип interface? В этом случае, боюсь, вы вообще не понимаете, для чего он предназначен. Причем, это костыли стыковки с Microsoft OLE, c громоздкой и ужасной попыткой реализовать объектную ориентированность на языке, не поддерживающем объектной модели (true C).

Так что... гибкость налицо, товарищи. в C++ тоже так можно, но в паскале это всё сделано практически почти что на уровне языка.

Отличная гибкость, когда сам язык завязан под 90% на реализации его RTL. В С++ хоть все честно - язык отдельно, библиотеки отдельно; а тут в ядре - и I/O и все прочее. К слову, никогда не интересовались вопросом поставить и эксплуатировать FPC на linux без графики? Сам компилятор, не говоря уж об Lazarus зависит от громаднейшего количества системных библиотек, причем даже таких, которые в обычной жизни требуются очень редко.

Опять же, TClass поддерживается на уровне языка. И сказать: "создай мне объект такого-то определённого заранее не известного типа, который мне передастся" на паскале очень легко. Чего не скажешь о C++. Да и в других языках с этим проблемы.

Этот самый TClass - исключительно борландовская выдумка; вы будете удивлены, но в ихнем CBuilder, что формально есть С++, он таки тоже есть В других языках с этим нет проблем, тем более, в Object PAscal вы лишены возможности создать объект "заранее неизвестного типа"; а уж работа с наследниками через базовый класс мало отличается даже в рудиментарных реализациях объектной модели.

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

[Brainenjii]

А ничего, что они относятся к разным категориям поддерживаемых языков и совместно их использовать нельзя?

O RLY?

Про тип interface? В этом случае, боюсь, вы вообще не понимаете, для чего он предназначен. Причем, это костыли стыковки с Microsoft OLE

O RLY?

К слову, никогда не интересовались вопросом поставить и эксплуатировать FPC на linux без графики?

спасибо, открыли мне повод задуматься, как же у меня одна машина собирает проекты, а вторая - запускает их, и всё безо всяких иксов

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

То что Вирт всегда был противником ООП - не секрет. Равно как и то, что в конечном счете ООП появлялся во всех его творениях. По поводу стандарта - вы считаете что он один? Или что стандарты когда-либо успевали в ногу со временем?

[SSerge]

А ничего, что они относятся к разным категориям поддерживаемых языков и совместно их использовать нельзя?

O RLY?

Поясняю. В реализациях fcl/lcl нет ни одного объекта (class ), который мог бы оперировать экземплярами разных Object, а без этого смысла в применении этого самого Object не просматривается. Сомнительная возможность создать статический экземпляр не стоит всех сопутствующих неудобств.

Про тип interface? В этом случае, боюсь, вы вообще не понимаете, для чего он предназначен. Причем, это костыли стыковки с Microsoft OLE

O RLY?

Мы говорим об этом: http://www.freepascal.org/docs-html/ref ... 5-950007.1 или удивление вызывает нечто другое?

К слову, никогда не интересовались вопросом поставить и эксплуатировать FPC на linux без графики?

спасибо, открыли мне повод задуматься, как же у меня одна машина собирает проекты, а вторая - запускает их, и всё безо всяких иксов

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

По поводу стандарта - вы считаете что он один? Или что стандарты когда-либо успевали в ногу со временем?

Я считаю, что нынешняя реализация delphi/free pascal в качестве языка с базовым паскалем имеет только декоративные исторические корни. Это абсолютно другой язык, и даже не развитие основ.

[alexey38]

Это абсолютно другой язык, и даже не развитие основ.

Язык в части фишек стал другой. Но основные плюсы сохранились неизменно:
1. Высокая читаемость кода в сочетании с лаконичностью.
2. Быстрая компиляция, что позволяет компилятор использовать для рефакторинга.
3. Строгость типизации и прочая строгость кардинально уменьшает число "детских ошибок".
4. Довольно ясные ошибки компилятора, особенно по сравнению с С++.
5. Наличие гибких элементов: варианты, изначальные строки с динамическим выделением памяти (по сравнению с ужасными нуль-терминированными строками классического С, которые являются основной причиной ошибок в ОС), интерфейсы, динамические массивы.

[Brainenjii]

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

http://pastebin.com/nCXbu41n fpc установлен из rpm пакета с оф. сайта.

Сомнительная возможность создать статический экземпляр не стоит всех сопутствующих неудобств.

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

удивление вызывает нечто другое?

именно ^_^ Interface - это мощное средство в ООП. Без привязки к COM и т.п. Например, я интерфейсами пользуюсь только с {$interfaces corba}, без всяких GUID и прочего

Это абсолютно другой язык, и даже не развитие основ.

Откройте исходники hedgewars. Будет похоже на "базовый" паскаль?
Разные подходы. Виртовский паскаль - структурное программирование, ObjectPascal, внезапно, все тот же старый паскаль + OOП надстройка. Чем не развитие основ?

[debi12345]

К слову, никогда не интересовались вопросом поставить и эксплуатировать FPC на linux без графики? Сам компилятор, не говоря уж об Lazarus зависит от громаднейшего количества системных библиотек, причем даже таких, которые в обычной жизни требуются очень редко.

??? FPC по "линем" как раз 1) заводится с одного пинка и 2) позволяет "клепать" программы без завязки на библиотеки (хотя и бОЛьшего размера - у меня консольный WEB-робот на базе FPC+MSEgui+Synapse получился около 300К)

Вы про что это? Про тип interface? В этом случае, боюсь, вы вообще не понимаете, для чего он предназначен. Причем, это костыли стыковки с Microsoft OLE, c громоздкой и ужасной попыткой реализовать объектную ориентированность на языке, не поддерживающем объектной модели (true C).

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

[FedeX]

Я тоже интерфейсы последнее время пользую только в режиме {$interfaces corba}, они тогда ведут себя почти как интерфейсы в языке ява. Только недавно с какой-то проблемой сталкивался по этому поводу - кажется было невозможно переменную типа интерфейса преобразовать в ссылку или класс, недоработка компилятора как я понял. А интерфейсы в режиме КОМ - действительно выглядят немного костыльными в паскале и не вносят ясности в проект если они в перемешку с обычными классами.. Ни для чего кроме как для работы с СОМ/ОЛЕ я бы их не использовал.
А обджекты очень даже выручают при программировании трехмерной или двухмерной графики реального времени например их можно хоть пачками создавать, работать так с векторами и матрицами..

[debi12345]

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

Еще на их базе сделана мощная библиотека шаблонов и STL-алгоритмов:

http://ignum.dl.sourceforge.net/project/decal/DeCAL/1.0.0/decal_rel_v1.zip