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

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

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

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

Да уж, до хаскеллевских фреймворков пхп ещё далеко.

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

> Смысл, в языках-то со слабыми типами?

Ты вообще отличаешь динамическую типизацию от слабой/нестрогой?

>> Смысл, в языках-то со слабыми типами?

Ты вообще отличаешь динамическую типизацию от слабой/нестрогой?

Да. А ты?

>Раскидывания контролов по формочкам с прототипизированием не путайте.

Это смотря что прототипировать. Если контролы на формочках...:)

... то путать частный случай с общим не стоит тоже.

Кстати, дельфи для этого не очень.

Это смотря что прототипировать. Если контролы на формочках...:)

Контролы на формочках, кстати, отлично прототипируются в старом добром текстовом режиме. Диалоговом, ага. Ты программе - «я нажал кнопку номер восемь», она тебе - «я упала в BSOD».

В прототипе-то важны не рисунки на кнопочках, а как эти кнопочки взаимодействуют.

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

Имел честь попробовать оба подхода :)

>В прототипе-то важны не рисунки на кнопочках, а как эти кнопочки взаимодействуют.

Это смотря какой прототип. Если прототип программы «вот тут будет табличка с записями а вот тут кнопки добавить удалить закрыть» то не надо недооценивать делфи на этой ниве:)

да к стати: http://www.linux.org.ru/forum/development/6104856?lastmod=1301857485069

Возникают как минимум две трудности: необходима соответствующая организация кода и имеются проблемы сопровождения (я имею в виду громоздкость результирующих композиций).

Беспредметно. Поменяйте местами «ФВП» и «макросы» и получится столь же осмысленная фраза.

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

Это не дельфи, это фотошоп нужен.

>Не знаю, что собрался прототипировать yaws,

Например работу микроядра
http://ertos.nicta.com.au/research/sel4/

но я - софт для цифровой обработки сигналов.

Интересно было бы посмотреть - есть исходники в открытом доступе ?

Интересно было бы посмотреть - есть исходники в открытом доступе ?

Боюсь, моё начальство не оценит стремление к открытости – бывшая госорганизация, даже допуск делают (по 3-ей форме, но всё-таки).

Большой офф.

А это не вы начинали писать пакет для R Project for Statistical Computing под названием RGMDH?

>проигрыш в производительности

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

Кстати, не проходи мимо хаскелевских же проектов atom и copilot. Как видишь — пресловутый ембеддед и прословутый риалтайм.

>Боюсь, моё начальство не оценит стремление к открытости

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

тот же С на несколько порядков более применим в реальной жизни.

Ой ли? C? У него очень маленькая ниша - суровый ембед, может быть, драйвера...

> программа не является функцией, не так ли?

Является. Сигнатура ее - IO ().

>Это не дельфи, это фотошоп нужен.

Неинтерактивно и требует скила - просто другого.

Что ж,поздравляю.

>Ой ли? C? У него очень маленькая ниша - суровый ембед, может быть, драйвера...

embedded devices - это та ниша которая сегодня приносит баснословные прибыли, а значит актуальна как никогда, PC для домохозяек от Microsoft остались в прошлом тысячелетии.

Поменяйте местами «ФВП» и «макросы»

Ну почему же?

Если позволите, я приведу пример на Nemerle

// исходный код
public class С
{
    public m(s :T): T { ... }
}
val c = C();

c.m(x);

// Без макросов
public class С
{
    public m(s :T): T { ... }
}
val c = C();

def a1(f: T->T): T->T { ... }

def a2(f: T->T): T->T { ... }

def a3(f: T->T): T->T { ... }

// Использование
val f = с.m;
a1( a2( a3(f) ) ) (x);

//или так
val a = (x: T->T) => a1(a2(a3(x)));
a(с.m)(x);

// С макросами
using Nemerle.Aop;
...
public class С
{
    public m(s :T): T { ... }
}
val c = C();

[aspect]
public class A1 {
    around(x : T) : T : execution(C.m(.., x : T, ..): T) {  ... }
}

[aspect]
public class A2 {
    around(x : T) : T : execution(C.m(.., x : T, ..): T) {  ... }
}

[aspect]
public class A3 {
    around(x : T) : T : execution(C.m(.., x : T, ..): T) {  ... }
}
// Использование
с.m(x);

Я. Упреждая следущий вопрос: нихрена там не написано про причиние резкого и внезапного изменения приоритетов.

>это та ниша которая сегодня приносит баснословные прибыли

То-то ребята из Galios Inc. используют для этих целей хаскель...

>> программа не является функцией, не так ли?

Является. Сигнатура ее - IO ().

это в какой операционной системе у программы тип IO ()?

понял, что мня неправильно поняли.

под «программой» - я имел ввиду исполняемый файл, который при запуски выполняет ввод/вывод. ф-и этим не занимаются.

>То-то ребята из Galios Inc. используют для этих целей хаскель...

Используют эти ребята Haskell - флаг им в руки, но я не встречал еще ни одного проекта в embeddedd где-бы не использовался C - те же реализации L4 api - либо С++ с ассемблером и биндинги к различным языкам, в первую очередь для С в user level либо вообще реализация на С как в индусском стартапе b-labs.

Является. Сигнатура ее - IO ().

А IO () не является функцией (так как не содержит "->").

>Разница в использовании, я бы сказал, разительная.

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

// Использование
с.m(x);

А можно для не владеющих немерлем прояснить, что происходит в случае макросов?

>А можно для не владеющих немерлем прояснить, что происходит в случае макросов?

Компилятор поставил всю ту кучу кода around который обозначет как aspect в матчащих сигнатуре pointcutах (вызовах).

я не встречал еще ни одного проекта в embeddedd где-бы не использовался C

Вроде, Зуйков со своим Бипом делал что-то в таком духе. Не помню точно.

Компилятор поставил всю ту кучу кода around который обозначет как aspect в матчащих сигнатуре pointcutах (вызовах).

То есть, исходный метод c::m теперь хрен вызовешь?

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

facepalm...

Не так было. Язык прикольный да и не так уж сложно сделать ЭВМ под него заточенный => делаем

см. выше по ветке

Спасибо за ответ, я свяжусь с вами ближе к лету, так как хочу написать МГУА для R в качестве части магистерской работы. И потом, если можно будет выложить в публичный доступ в качестве пакета.

>То есть, исходный метод c::m теперь хрен вызовешь?

Угу. Прикольно да?

Типа задумывалось как метода организации «независимого кода» - например логгинг и основнная логика 'теоретически логически не пересекаются и потому могут писаться независимо' типа киллертехнология второй половины первой половины двухтысячных годов.

На практике все свелось к 'метод который вызвать до и(ли) после взова другого метода'.

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

Потому оно где-то там практически умерло - хотя очень много людей дергалось.

>см. выше по ветке

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

> Например работу микроядра http://ertos.nicta.com.au/research/sel4/

Если кому интересно, видео: http://corp.galois.com/blog/2011/2/25/tech-talk-video-verifying-sel4-based-sy...

>Вроде, Зуйков со своим Бипом делал что-то в таком духе.

Вы меня не поймите неправильно - ничего не имею против Haskell, наоборот, в исследовательских проектах таких как микроядро L4 языки очень тесно переплетаются - аппаратно-зависимая часть на ассемблере, основная часть кода на С++, системы сборки на Phyton, встраиваемые скрипты на Lua, верификация на Haskell - для всего есть свое место, просто не нужно нос слишком сильно задирать :)

Ах да - забыл еще что в TU Dresden в качестве препроцессора Perl используют.

>> я не встречал еще ни одного проекта в embeddedd где-бы не использовался C

Вроде, Зуйков со своим Бипом делал что-то в таком духе. Не помню точно.

Луговский, помнится, для embed очень Forth пропагандировал, как метаязык. Кстати, он ещё и функциональный.

> Не так было.

Учимся дорассказывать истории до конца:

Язык прикольный да и не так уж сложно сделать ЭВМ под него заточенный => делаем

... => ох*еваем от того, какое оно получилось тормозное => сливаем (по очереди) мейнфреймам, кластерам и обычным ПеКа => выкидываем розовые очки, а вместе с ними и чудо-мойшину, на свалку истории.

Угу. Прикольно да?

Прикольно.

По-нормальному я бы просто написал обёртку над C, вызывающую нужные методы, и вместо {c = C(); a(c.m)(x);} писал бы {c = D(); d.m(x)}, без всяких там левых макросов. В Хаскеле есть ещё фокус, когда тип делают достаточно полиморфным, что позволяет отловить все его использования (см. штуки типа автоматического дифференцирования).

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

Луговский, помнится, для embed очень Forth пропагандировал, как метаязык.

Мейби, мейби. По крайней мере, если у нас есть железка, для которой нет НИЧЕГО ВООБЩЕ и надо что-то написать прямо в кодах, начать с Форта - идея здравая.

Кстати, он ещё и функциональный.

In your lonely, pathetic dreams.

>По крайней мере, если у нас есть железка, для которой нет НИЧЕГО ВООБЩЕ и надо что-то написать прямо в кодах, начать с Форта - идея здравая.

Это где в РФ делают такие желески ? самое крутое что видел в общем доступе - какой-то клон китайского MIPS от подмосковной конторки..

Ок, из собственной практики.
1. Развешивание на часть методов объекта кода изменения формы графического курсора при запуске «долгоиграющих» расчетов.
2. Проверка прав доступа к объекту.
3. Протоколирование работы программы.
4. Контроль доступности методов объекта для потоков.

1. setcursor(pointer) {
code....
}

2. ensureaccess(user) {
......
}

a) Откуда контест проверки берется?
b) Что делать если надо иногда оверрайднуть этот access?


3. Протоколирование работы программы.

угу - про это я сказал - AOP - король трейсов.

4. не понял.