Вышел FreePascal 2.4

Код необходимо отделять от интерфейса

Вариант на С

#include <stdio.h>
#include <stdlib.h>

struct TMas
{ int M, N;
  int * data;
};


void  TMas_init(struct TMas * m, int M, int N)
{ m->data = (int *)malloc(sizeof(int)*M*N);
  m->N = N;
  m->M = M;
  int i;
  for (i=0; i<(M*N); i++) m->data[i]=i;
}

void TMas_print(struct TMas * m)
{ int i,j;
  for (i=0; i < m->N; i++)
  { for (j=0; j < m->M; j++) printf("%i ", m->data[i * m->M + j]);
    printf("\n");    
  }
}

int main()
{   struct TMas m;

    TMas_init(&m, 10, 20);
    TMas_print(&m);
    return 0;
}

impfp> Так может в этой «куче» и есть ниша паскакаля? :)

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

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

Если интерфейс будет один, то зачем отделять то?

Если интерфейс будет один, то зачем отделять то?

некорректная формулировка: не «будет один», а «планируется один»... а заказчик через полгода после сдачи придёт и скажет «ой, а нам тут надо другой интерфейс» и что, будете всё переписывать?

> > А давайте, может, сразу тогда определимся: для решения каких задач следует использовать сабж (к дельфям тоже относится)? По ответу сразу всё встанет на свои места :)

Если кратко - паскаль уже не нужен. Есть более подходящие средства.

Ну вот этого я и намеревался услышать. Что и требовалось доказать, как говорится.

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

anonymous> Если интерфейс будет один, то зачем отделять то?

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

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

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

yet_another_anon> Ну, не хватает звёзд с неба, но что-то набросать по-быстрому - лучше и не придумать.

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

yet_another_anon> И работает быстрее, чем питон, кстати.

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

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

Давайте проверим работоспособность вашей технологии и напишем, например - калькулятор.

mem leaks...

>Сначала пишу консольную программу

Про разделяемые библиотеки ты конечно не слышал.

anonymous> Оценить вероятность множества интерфейсов к одной программе можно просто посчитав кол-во программ с различными видами интерфейсов. Их колличество ничтожно, стало быть и вероятность такого исхода событий мала. И вообще такие вещи нужно оговаривать с заказчиком заранее.

Ужасно глупое суждение в своём корне.

Относительно интерфейсов - зависит от поставленной задачи и заказчика. И вероятностью оценивать это глупо.

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

Теперь возьмём крупную контору, которой нужна система автоматизации части деятельности. Имеем: филиалы конторы, каждый со своим офисом; огромный документооборот; в сами офисах компьютеров не меньше 10; необходима удобная связь с остальными частями конторы; необходима связь с СУБД FireBird или Oracle, а то и DB2; и т.д.
Вот тут уже придётся хорошенько думать: скорее всего понадобится несколько интерфейсов - оконный локальный интерфейс, вебморда, может для мобильников на жабе захотят простенький и т.д. И даже паскаль тут идёт лесом.

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

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

>«взаимоисключающие» параграфы взорвали неокрепший моск? :)

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

anonymous> Про разделяемые библиотеки ты конечно не слышал.

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

kss> Что и требовалось доказать.

Что доказать? Что ты за свои слова не отвечаешь?

anonymous> Давайте проверим работоспособность вашей технологии и напишем, например - калькулятор.

Возьмём питон... И видим, что он и есть калькулятор. И калькулятор - неудачный пример. Хотя бы потому, что арифметические операции обычно поддерживаются самим языком. Так что тут просто нет смысла писать сначала консольную программу - логика реализована в самом языке.

Не-а. Что 90% твоих сообщений — хамство)

да тут половина его либо незнает, либо помнит что-то из школы-универа-еще-какого-уза, у одного туго с указателями, у другого - с массивами, третьему - lazarus не нравится, вот и обсирают :)

Нет чтобы обсудить реальные недостатки fpc, как то: невозможность возврата generic значений, отсутствие механизма рефлексии (о, rtti...), как следствие - отсутствие достаточно общих контейнеров (jcl lists, например, это так убого...). невозможность вернуть указатель на локальную функцию... Вот что можно было бы обсуждать. А то - «ненужен, тока незнаю - почему». ;)

>Если говорить о том, что надо что-то набросать быстро, то лучше помалкивать о производительности. Ну, я говорю о сумме показателей. То есть, разработать что-то быстро, собирается и пересобирается оно быстро, работает тоже быстро. Для чего-нибудь совсем простого я скорее выберу паскаль, чем питон. Для чего-нибудь более сложного - скорее джаву ;)

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

Давайте оценим вероятность такого исхода событий.

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

И трудозатраты на оба варианта.

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

И вообще такие вещи нужно оговаривать с заказчиком заранее.

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

даже в идеальном случае заказчик потом может придти и сказать «мне нужно чтобы теперь это было так, сколько Вы денег за это хотите?»

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

короче курите паттерн mvc

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

Или пишешь оконный и ставишь на терминальный сервер.

Или пользуешь 1С 8.2 и получаешь локальный оконный интерфейс и Web интерфейс.

Вообщем зачем отделять интерфейс в вашем случае не понятно.

kss> Не-а. Что 90% твоих сообщений — хамство)

Твоя выборка не является репрезентованной. Учи статистику, невежда.

anonymous> Вообщем зачем отделять интерфейс в вашем случае не понятно.

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

yet_another_anon> То есть, я не то что бы фанат паскаля, но я совершенно не понимаю, откуда столько агрессии по поводу него. Добротный, стабильный, простой и быстрый язык. Хай себе живёт.

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

«которые на него возлагались»

Да ничего на него Вирт, кроме обучения структурному программингу, и не возлагал. Задачи о которых Вы говорите, предполагалось возложить на Аду и/или Оберон.

так как некрофилия не есть хорошо.

50-летний lisp? ))) Мосье Луговски сожрал бы вышу печень на завтрак :)

Я вообще не понимаю, как к ЯП может быть применено понятие «некрофилия».

> То есть, я не то что бы фанат паскаля, но я совершенно не понимаю, откуда столько агрессии по поводу него. Добротный, стабильный, простой и быстрый язык. Хай себе живёт.

Не в этом дело. Начнём с того, что он ничем особо не лучше языков своей категории, а самое главное то, что своей ниши, как и кресты (ох, сейчас начнётся срач), не имеет.
Вывод: зачем оно нужно, если код потом придётся ещё и поддерживать, не проще ли сразу сделать «как надо» и не мучаться?

Я вообще не понимаю, как к ЯП может быть применено понятие «некрофилия».

а Вы попробуйте на коболе программы пописать

С заказчиками общался и не раз. Они понятия не имеют о видах интерфейса. Для них главное чтобы работало.
Трудозатраты разные и зависят от уровня абстракции.
Чаще mvc только увеличивает код, и не способствует его эффективности, при этом не добавляет возможности получить доп. вид интерфейса.

impfp> Да ничего на него Вирт, кроме обучения структурному программингу, и не возлагал.

Зато другие возлагали. И задачи вполне решались.

impfp> Я вообще не понимаю, как к ЯП может быть применено понятие «некрофилия».

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

Если это была просто история из жизни, вне контекста с динамическими массивами, дескать, и даже с маршалингом приходилось сталкиваться, то, извиняюсь, не понял.

С заказчиками общался и не раз. Они понятия не имеют о видах интерфейса. Для них главное чтобы работало.

так а что тогда на заказчиков киваете?

Трудозатраты разные и зависят от уровня абстракции.

эммм? Вы в трудозатраты что включаете?

Чаще mvc только увеличивает код, и не способствует его эффективности, при этом не добавляет возможности получить доп. вид интерфейса.

1) чаще чего?

2) «пошли дурака молиться - он и лоб расшибёт» (с)

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

Для этого уже есть СУБД. И не нужно заново изобретать mvc;
Для этого уже есть веб сервера. И не нужно заново изобретать mvc;
Для этого уже есть терминальные сервера. И не нужно заново изобретать mvc;

>Для моих нынешних задач вынос функций в библиотеки не имеет смысла

А как же ты собрался гуй писать? Неужели через pipe дёргать?

Плюс сначала проще сделать работающую программу, и только потом решать, что и куда.

Конечно, пока сделаешь парсинг выхлопа, то на другое времени не остаётся :D

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

Для этого уже есть СУБД. И не нужно заново изобретать mvc; Для этого уже есть веб сервера. И не нужно заново изобретать mvc; Для этого уже есть терминальные сервера. И не нужно заново изобретать mvc;

не, не, не Дэвид Блейн речь не о том... это может быть и не известно в начале проекта, а потребуется впоследствии

Вот видишь? Интерфейс будет уже отделён от логики.

На нём пишется легко, поддерживается легко, никаких особо сложных проектов на нём всё равно не написано (в отличие от тех же плюсов, кстати, где чем в чужом коде разобраться часто проще заново написать). Можно сказать, такая и есть его ниша - простые и быстрые программки. Ну и несложные красивые игрушки типа Hedgewars ;)

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

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

чаще чего?

«пошли дурака молиться - он и лоб расшибёт» (с)

т.е по существу вопроса возразить нечем.

anonymous> А как же ты собрался гуй писать? Неужели через pipe дёргать?

1. Наворотить над уже имеющейся программой прямо в коде (функции есть - осталось поставить GUI)

2. Если уж совсем много - в отдельную библиотеку вынести. Но то, что я сейчас пишу, не такое большое.

Я имел в виду лишь то, что реализации открытых массивов вчера-сегодня-завтра вообще мне неинтересны.

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

Ну... тут вопрос такой... MVC для клиента - пустой звук, для разработчика, особливо, стороннего - способ быстрее разобраться с кодом... Хотя и лажа бывает. Например, dotnetnuke - сколько модулей под него напейсано, столько и «видений» MVC :)

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

не надо ляля, вот Ваша фраза:

И вообще такие вещи нужно оговаривать с заказчиком заранее.

и следующая:

С заказчиками общался и не раз. Они понятия не имеют о видах интерфейса. Для них главное чтобы работало.

не ощущаете пресловутого диссонанса?

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

ну пусть так хотя я тут не вполне согласен... насчёт времени - это понятно, я имел в виду из каких составляющих состоит это время

> «пошли дурака молиться - он и лоб расшибёт» (с) т.е по существу вопроса возразить нечем.

это вполне по существу, или расшифровать?

Вот видишь? Интерфейс будет уже отделён от логики.

От бизнес логики.
Или логики работы интерфейса?
Или логики обработки данных?

И если уже отделен, что для этого сделал программист при создании клиентского приложения. Использовал готовые компоненты Lazarus?

Использовал готовые библиотеки php?

Использовал готовые СУБД?

надо будет - обязательно попробую ;)

Пока суд да дело, я вижу он как-то но живет и вроде бы даже здравствует

>Наворотить над уже имеющейся программой прямо в коде

А как же принцип «гуй отдельно»?

надо будет - обязательно попробую ;)

я про то что программирование на нём вполне смахивает на некрофилию :)

или Вы намекаете что «некрофилия» не может быть применена непосредственно к языку так как «некрофилия» это действие? :)

не ощущаете пресловутого диссонанса?

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

из каких составляющих состоит это время

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