LINUX.ORG.RU

Вышел FreePascal 2.4

 , ,


0

0

FreePascal — это кросс-платформенный, свободный компилятор и библитека RTL языка pascal.

Добавлены новые платформы:

  • 64-бит Mac OS X (x86_64/ppc64)
  • iPhone (Mac OS X/Arm)
  • Haiku
  • Улучшена поддержка ARM EABI

Некоторые изменения:

  • файл ppc386.cfg больше не используется;
  • переменные Absolute теперь поддерживаются;
  • добавлено выравнивание для переменных типа record;
  • добавлены типы Byte/Word/Long/Qwordbool;
  • все старые модули сокетов для версии 1.0.x были удалены.

User changes

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: alexsaa (всего исправлений: 3)
Ответ на: комментарий от shty

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

Quasar ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от Quasar

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Quasar ★★★★★
()
Ответ на: комментарий от shty

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

1) чаще чего?

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

shty ★★★★★
()
Ответ на: комментарий от Quasar

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

чаще чего?

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

impfp
()
Ответ на: комментарий от anonymous

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

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

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

и следующая:

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от anonymous

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

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

shty ★★★★★
()
Ответ на: комментарий от Quasar

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

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

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

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

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



anonymous
()
Ответ на: комментарий от shty

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

конечно не ощущаете, поэтому и пытаетесь указать мне на то что в ТЗ надо прописать вещи которые «заказчика не заботят», более того, вещи о которых заказчики «понятия не имеют»... ещё раз: в общем случае, Вы ошибаетесь

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

Из производительных и непроизводительных затрат.

Производственных и непроизводственных Вы имеете в виду?

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

Разделение модулей банально позволяет изменять одну часть проекта не трогая другую, что очень ВАЖНО, так как порой регрессионное тестирование проекта целиком может занимать значительное время.

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

ололо, а ведь Вы и правда ведь расшибёте лоб если Вас послать... ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта (если его использовать с умом конечно)

shty ★★★★★
()
Ответ на: комментарий от Quasar

И? На fpc можно сделать и локальную морду, и веб-интерфейс (в lazarus - с мышевознёй, аяксом, блекджетом и шлюхами - http://code.google.com/p/extpascal/ - даже завёл на локалхосте, пока не баловался особо ^_^), вот только с мобильниками проблема... Кстати, когда пришлось - на яву не заморачивался, а тупо сделал простенький сайтик и встроенными браузерами на него заходил ^_^ Сайтик, опять же, - cgi модуль на fpc ^_^ Правда в конечном итоге решили, что не нужно ^_^

anonymous
()
Ответ на: комментарий от shty

По поводу ТЗ и интерфейсов - забавный случай был ^_^ Попросили в маркетинговом сделать для них программку, а я занят был, сказал - «Ну, несите ТЗ, там посмотрим» ^_^ Принесли - папку с кучей рисунков форм и «рассказами» - что будет, если нажать ту, или иную кнопку :-D Как потом оказалось - пришлось даже с магнитными картами дисконтными учиться работать ^_^

anonymous
()
Ответ на: комментарий от shty

более того, вещи о которых заказчики «понятия не имеют»... ещё раз: в общем случае, Вы ошибаетесь


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

Вы не рассматриваете трудозатраты на ведение проекта.

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

Со временем будут накапливаться ошибки которые придётся устранять, и не говорите мне что при «правильном программировании» ошибок не бывает

Вы телепат?

ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта


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

ололо, а ведь Вы и правда ведь расшибёте лоб если Вас послать...

Снова телепатия?

ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта (если его использовать с умом конечно)


Я не против mvc в принципе. Естественно её (модель) нужно применять с умом. Речь шла об отделении интерфейса от реализации, о том что этого избегать нелья. Я говорю о том, что в некоторых случаях можно. А в других о этом за вас позаботились разработчики библиотек Qt или VCL. К тому-же часто читал на ЛОРе о том что такое разделение якобы легко позволяет реализовать различные виды интерфейсов (web, WIMP). Это не так. Это сложная задача, которая под силу далеко не всем командам разработчиков. И примеров реализации этой идеи исчезающе мало. Тратить время на реализацию этой идеи глупо, эсли вы не разработчик мега GUI библиотеки.
<telepat>
И не нужно думать, что код моих программ состоит из одной функции
в одном модуле. Или из одного класса. Или что мне не известны способы
распределения работ между исполнителями.
</telepat>

anonymous
()
Ответ на: комментарий от anonymous

Теперь я понимаю почему ваши заказчики могут менять задание на ходу.

Ну что Вы Равшана с Джамшутом от программирования изображаете? ТЗ могут меняться в силу разных обстоятельств, не всегда зависящих от меня или даже от моих заказчиков. В таком случае ТЗ мне помогает описать изменения которые необходимо будет внести в проект и обосновать стоимость и перенос сроков. И по результатам переговоров, коли заказчик доволен, составляется дополнение к ТЗ. Так понятнее?

> Вы не рассматриваете трудозатраты на ведение проекта.

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

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

Я не против mvc в принципе. Естественно её (модель) нужно применять с умом.

конечно, тут договорились :)

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

А где я на это возражал?

А в других о этом за вас позаботились разработчики библиотек Qt или VCL.

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

shty ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.