Вышел FreePascal 2.4

> А на каком языке другие варианты? с, с++?

На Си вариант хорошо тем, что (1) позволяет нюхнуть полроху в лице указателей (2) очень эффективен (3) сност мозг. Я про вариант, где в начале хранят указатели на строки, а потом (в этом же массиве!) сами строки.

слабо написать на Баше скрипт, который будет конвертить файл конфигурации смайликов майл-агента в файл для Пси при помощи регулярок и седа? Я такое делал када-то. )) Правда была проблема с анимированными смайлами, на них пришлось забить. =/ А начинал я с Паскаля когда-то... )

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

И что сказали в университете? «А теперь --- будет использоваться!»? %)

> слабо написать на Баше скрипт, который будет конвертить файл конфигурации смайликов майл-агента в файл для Пси при помощи регулярок и седа? Я такое делал када-то. )) Правда была проблема с анимированными смайлами, на них пришлось забить. =/ А начинал я с Паскаля когда-то... )

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

> А на каком языке другие варианты? с, с++? Длину явно везде указывать надо, или использовать классы для матриц.

Мдя. @r и есть матрица MxN. Запускать, разумеется из под root:

$ perl -MData::Dumper -e '@r = ([2,3], [4,5]); print Dumper(@r)'

> Обоснуй.

Быдлоязык?

Оно то может и было. Но в совке этого не было, было доступно только foxpro

>На Си вариант хорошо тем, что (1) позволяет нюхнуть полроху в лице указателей

Давай ставним идею «динамического массива», аллоцируемого через malloc(), с другими вещами которых учат инженеров. Проще осилить malloc()/free() чем метод наименьших квадратов или хи-квадрат критерий, например? А если с сопроматовскими умениями типа построения эпюр сравнить?

> Давай ставним идею «динамического массива», аллоцируемого через malloc(), с другими вещами которых учат инженеров.

Давай, но зачем? Я считаю, что malloc прочнисту нужен так же, как эпюры --- профессиональному программисту. То есть --- не сдались

А если с сопроматовскими умениями типа построения эпюр сравнить?

Я эпюры освоил в школе, а в МУ-61 маллока у меня не было >_<

> Оно то может и было. Но в совке этого не было, было доступно только foxpro

поэтому совок и просрал ИТ (или CS?)

>> Оно то может и было. Но в совке этого не было, было доступно только foxpro

поэтому совок и просрал ИТ (или CS?)

ЕМНИП, FoxPro появился, когда совка уже не было...

Если что-то не применимо к Free Pascal, поправьте. Говорю о Delphi.

1. Большее количество кастов.

2. Малое количество компиляторов выского качества.

3. Низкая распространенность

4. Не предлагает решения никаких проблем, которые не решаются так же легко или легче на других языках

5. Неудобство обьявления переменных в начале функции

6. Отсутствие краткой записи многих математических операций, тренарного оператора

7. Шаблоны. Слышал что в FP такое есть. Да? Достаточно ли оно мощное для создания аналогов STL (alogirithms, iterators, etc)

8. Скептическое отношение со стороны большинства программистов )

Ну наконец-то! :) И срач в наличии :)

2. Малое количество компиляторов выского качества.

Нафуй этот зоопарк, пофапать? 8)

3. Низкая распространенность

Не аргумент

4. Не предлагает решения никаких проблем, которые не решаются так же легко или легче на других языках

Любую задачу можно решить с помощью любого вменяемого ЯП. Pascal, как и другие языки высокого уровня - язык «широкого профиля» и не является узкоспециализированным.

7. Шаблоны. Слышал что в FP такое есть. Да? Достаточно ли оно мощное для создания аналогов STL (alogirithms, iterators, etc)

В оригинальном Delphi(версии 2009 кажись, или раньше) тоже появилось подобное, в виде дженериков, но деталей я не знаю.

8. Скептическое отношение со стороны большинства программистов )

стадный эффект, очевидно же :)

О, generics в fpc!.. ;-)

Кстати, в fpc 2.4rc foreach конструкцию представили, а в новости этот момент как-то не учтен(?).

>Улучшена поддержка ARM EABI
хмм.. Зачем?

>Я про вариант, где в начале хранят указатели на строки, а потом (в этом же массиве!) сами строки.

Нет никаких проблем сделать точно такую же структуру данных и в паскале.

>>как же на паскале принято передавать в функцию матрицу MxN

var P: Pointer

И эти люди запрещают нам ковыряться в носу ?

type tSomeArray = array [0..M,0..N] of tSomeType; function foo (arg : tSomeArray);

И все. Причем проверку корректности индексов массива и отслеживание выхода за границы сделает сам компилятор.

tSomeType может быть любым допустимым типом.

1. В поставленной задаче M и N меняются динамически, а в вашем примере это константы
2. function foo (var arg : tSomeArray);
- лучше передавать как var, тогда массив будет передан по ссылке

И вообще одномерный массив легко приводится к двумерному,
динамическиие массивы во free паскале есть, так что вообще не вижу проблемы

type

T2DimArray = record
data: array of integer;
M,N: integer;
end;

procedure T2DimArray_Init(M,N: integer; var a: T2DimArray);
var
i: integer;
begin
setlength(a.data, M*N);
for i:=0 to M*N-1 do a.data[i]:=i;
a.M:=M;
a.N:=N;
end;


procedure T2DimArray_Print(var a: T2DimArray);
var
i,j: Integer;
begin
writeln('Printing');
for i:=0 to a.N-1 do
begin
   for j:=0 to a.M-1 do write(a.data[i*a.M+j],' ');
   writeln('-');
end;
end;

var
A: T2DimArray;
begin

T2DimArray_Init(20,10,A);
T2DimArray_Print(A);
end.

>И что сказали в университете? «А теперь --- будет использоваться!»? %)

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

>type tSomeArray = array [0..M,0..N] of tSomeType; function foo (arg : tSomeArray);

сказано же - переменные M и N, умник. С каких это пор в паскале можно делать так, если M и N не константы?

anonymous> Это подойдет для _большинства_ студентов? Это подойдет для _большинства_ задач? (не только по выч. мату, есть ведь еще и другие).

То есть ты предлагаешь делать их студентов даунов, которые офигенно криво решают задачи? Удавись пожалуйста. Мышевозная разработка - это не программирование, а быдлокодерство by design.

как же на паскале принято передавать в функцию матрицу MxN

Миллион лет уже не писал на паскале, но попробую, за склероз простите :)

procedure P(const a: array of double; M,N: word);

Вроде так.

сказано же - переменные M и N, умник. С каких это пор в паскале можно делать так, если M и N не константы? сказано же - переменные M и N, умник.

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

type tArray = array of tSomeType;
tMatrix = array of tArray;
function foo (arg : tMatrix);

В паскале кстати массивы всегда передаются по ссылке.

>Людям [...] не учившим [...] джаву - C++ ненужен\вреден.

facepalm.txt

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

нет, от того, что система типов в Паскале — гавно =)

>> 2. Малое количество компиляторов выского качества.

Нафуй этот зоопарк, пофапать?

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

3. Низкая распространенность

Не аргумент

именно аргумент, причём - ООООЧЕНЬ весомый !!! всегда при разработке более-менее сложного проекта возникает неоходимость взять чужие компоненты, глянуть в чужие исходники, чтоб не ваять велосипеды с нуля. ну хотя бы (как пример) - XML-парсер простенький нужен. и при малой распространённости языка - где я чужие сорцы возьму, позырить код, взять компоненты для разработки и перенять чужой полезный опыт ? так что не правы вы, Andru.

> Нет никаких проблем сделать точно такую же структуру данных и в паскале.

Во Free --- нет, я знаю. Только на Си такое решение выглядит раза в три элегантнее, поэтому не ясно, зачем нам Паскаль. Для современного Паскаля кошерен двойной open array.

>Уже вспомнили выше.

Да и вообще, следуя Вашей логике, в отстой надо отправить что C/C++, что Java. Меня вот и правда интересует такой вопрос: чего же такого фундаментального не хватает Delphi, чтобы писать на нём грамотные, хорошо спроектированные программа? Хотелось бы услышать грамотный, технически аргументированный ответ, а не тупые выкрики. Skype вот пишет свой клиент на Delphi, и ничего, знают что делают. И наоборот - вокруг полным-полно ужасных программ на C++ и Java.

gambas?

>Skype вот пишет свой клиент на Delphi

вот в моей убунте (crunchbang linux) скайп-клиент был по умолчанию установлен, часто его юзаю. тоже на делфях писали ? под линукс-то, а ?

>переменные Absolute теперь поддеживаются.

А почему?

>под линукс-то, а ?

Б! Если Вы настолько «умный», то специально для таких как Вы, уточню- Windows-версия клиента Skype написана на Delphi. Причем эта версия гораздо функциональнее линуксового кастрата, на который скайп вообще забил и отдал на разработку OpenSource-сообществу. Так понятнее?

>anonymous> Это подойдет для _большинства_ студентов? Это подойдет для _большинства_ задач? (не только по выч. мату, есть ведь еще и другие).

То есть ты предлагаешь делать их студентов даунов, которые офигенно криво решают задачи? Удавись пожалуйста. Мышевозная разработка - это не программирование, а быдлокодерство by design.

Полегче, брат. Будь повежливей, на лоре все-таки.

С чего ты решил, что паскаль/лазарус/делфи делает из студентов даунов? Как кто-то уже сказал (и я соглашусь с ним), паскаль хорош для обучения структурному программированию.

Что плохого в мышевозной разработке _гуи_? По-моему, это вполне оправдано.

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

> gambas?

Так это еще более «ненужно», чем паскаль/лазарус же :)

Ты давай нормальные альтернативы) Пока только QtCreator сказали :)

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

В недавней теме про Mono(Develop?) как-то даже замеряли сколько нужно времени на создание формочки с кнопкой и ХеллоуВорлду по этой кнопке под WinForms (под VCL почти то же самое). Любители понабивать лишние килобайты на клавиатуре тогда с треском проиграли. И да, Вы совершенно правы, нет никаких препятствий использованию в Delphi какого-нибудь собственного GUI-фреймворка как альтернативу тасканию компонентов на форму. Только разве красноглазым есть до этого дело?:)

> Да и вообще, следуя Вашей логике, в отстой надо отправить что C/C++, что Java.

Си нельзя. Это во-первых, кросплатформененый асм, очень концептуально правильный (никакой магии, всё тупо и просто), во-вторых, он незаменим в системном программировании.

В C++ есть шаблоны, неймспейсы, перегрузка операций, шизофрения. В Яве есть генерики, неймспейсы, интерфейсы и сталинизм, что концептуально. Ну и GC и библиотека приличная.

чего же такого фундаментального не хватает Delphi, чтобы писать на нём грамотные, хорошо спроектированные программа

Будем считать, что имелся в виду Delphi Classic. Фундаментального (для простого языка высокого уровня) --- неймспейсов, генериков, интерфейсов. Это по крупному. Во FreePascal пункт 2 пытались исправить, кажется, или уже? По мелочи: как на дельфи сделать хорошо спроектированную систему с интерфейсом пользователя, где будет вариант с гуём и с веб-мордой? Если знаете — просвятите.

>> gambas?

Так это еще более «ненужно», чем паскаль/лазарус же :)

Насколько я понимаю, gambas - единственная настоящая RAD-система под Linux :) В смысле, что поставил кнопочку, тыкнулся, написал её код. Вместо того, чтобы мучить отдельно дизайнеры, отдельно связи элементов и т.п.

>facepalm.txt

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

> Что плохого в мышевозной разработке _гуи_? По-моему, это вполне оправдано.

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

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

Place-des-Arts> Когда сменился препод по численной физике, было (справедливо) решено что это дико непедагогично, и Си поменяли на scipy. После чего против этого взбунтовалась студенческая ассоциация, ибо Питон совершенно не используется в физико-инженерной индустрии.

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

P.S.

А что за университет такой?

>Будем считать, что имелся в виду Delphi Classic. Фундаментального (для простого языка высокого уровня) --- неймспейсов, генериков, интерфейсов. Это по крупному. Во FreePascal пункт 2 пытались исправить, кажется, или уже? По мелочи: как на дельфи сделать хорошо спроектированную систему с интерфейсом пользователя, где будет вариант с гуём и с веб-мордой? Если знаете — просвятите.

Акститесь, уважаемый. Интерфейсы поддерживаются в Делфи уже черт знает сколько лет, генерики появились в Delphi2009, неймспейсы поддерживаются уже с Delphi2005. Насчет веб-морды - это Вы, конечно, отожгли... На эту тему целые книги написаны, в любом случае в современном Делфи есть куча всего для написания Web-приложений, включая новомодные Ajax'ы.

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

А у вас серьёзно C++ после Явы преподают?

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

Ага, а настоящие джедаи пишут исключительно на асме.

>Си нельзя. Это во-первых, кросплатформененый асм, очень концептуально правильный (никакой магии, всё тупо и просто), во-вторых, он незаменим в системном программировании. В C++ есть шаблоны, неймспейсы, перегрузка операций, шизофрения. В Яве есть генерики, неймспейсы, интерфейсы и сталинизм, что концептуально. Ну и GC и библиотека приличная.

Я не вижу фундаментальной причины зачем «кросплатформеному ассемблеру» объекты. В мире было бы намного меньше проблем и несчастий, если бы плюсов вообще не было. Был бы только C и высокоуровневые языки.

И система типов в паскале нормальная.
Это в C непонятно что, даже строк нормальных нету

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

Хм... Ну, что-то типа такого было (точно, конечно, не упомнить):

- Система команд Б3-34 и Basic (15)
- Focal, Си, asm 8080 (16)
- Forth, Си++, asm 8086, asm PDP (17)
...
- Java (25)
- Perl, PHP (26)

И совершенно не понимаю, что там во мне якобы вредного оставили Си/Си++, изученные до Java ;)

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

Это всё проблемы конкретных криворуких программистов. Вас просили озвучить фундаментальные ограничения Delphi как языка программирования, которые НЕ ПОЗВОЛЯТ написать хорошую программу. Допустим есть толковые архитекторы и программисты, ан нет - Delphi говорит: «нельзя!». Очень было бы интересно послушать.