Отправлено 04 ноября 2017 - 22:38
ну раз все знаете ... так пишите ... а то какую то охенею несете
)))
Спасибо за пример ... вот именно также это будет выглядеть на Delphi (конечно с учетом семантики)
Что и требоволось доказать ..... и не надо полемики
Не надо начинать обзываться на незнакомых людей в состоянии алкогольного опьянения.
Отправлено 04 ноября 2017 - 22:44
Не надо начинать обзываться на незнакомых людей в состоянии алкогольного опьянения.
Бирки начали вешать ... мне на правый палец , плииз ))
А по-сути ... ни на кого не обзывался ... просто попросил написать на Java 7 а не j8 как было в коде ... и указано что это Java 7 .... ))
Мне честно сказать монописуально .... в залупу просто не надо лесть ))))
И, да ... особенно взбесило, что вы даже не знаете как работает компилятор и начали гнать пургу 
(( .... обидно за молодое поколение
Отправлено 04 ноября 2017 - 22:57
И, да ... особенно взбесило, что вы даже не знаете как работает компилятор и начали гнать пургу
TRUST NO ONE
Отправлено 05 ноября 2017 - 01:41
В нем описывается последовательность действий: возьми элемент из исходной коллекции, проверь его и если надо, то добавь его в результирующую коллекцию. Очевидно, что распараллеливание в императивном подходе требует полного переписывания кода, потому что при параллельном исполнении у тебя совершенно другая последовательность действий. А при декларативном подходе ты не описываешь последовательность действий. И filter(name -> name.startsWith("J")).filter(name -> name.length() > 6) это не последовательность действий, это именно декларирование ожидаемого результата,
А по-моему, это одно и то же, но записанное в разной форме. Твой .stream().что-то там будет тем же самым for range'м внутри. Там то же самое итерирование с использованием фильтров, но в виде лямбд, внутри. Ты просто скрыл все то же самое за стеной библиотеки, вот и все. В твоем примере тру итеративного подхода никто не обязывает писать условия явно - ты можешь использовать а-ля callback универсальный, и вызывать его хоть из обычного forа, хоть из распараллеливающей библиотеки. Как сделал я, задекорировав это именами ...sequentially и inParallel:
Вот это:
ResultingCollection = processCollectionSequentially(InitialCollection, <вон та лямбда сверху>);
тот же самый твой for, тело которого вынесли в лямбду (сахар, там мог быть функциональный тип с тем же успехом).
Ты же записываешь .filter . filter .map .collect, а не .collect .filter . map . filter - последовательность действий имеет значение - сначала фильтрация, потом, если прокатило, апкейс, потом сборка, не наоборот. А в декларативном подходе можно было бы записать как угодно, в любой последовательности.
Или ты считаешь, что раз мы скрыли итеративный код в библиотеку, то он таковым перестал быть? Ну так давай мы код из твоего первого итеративного примера запихнем в функцию processCollectionAsINeededIt() и вся программа будет в виде:
main()
processCollectionAsINeededIt()
end;
Что, это тоже декларативный подход? Ну, мы же задекларировали, что хотим обработать коллекцию так как нам надо.
По-настоящему декларативный подход - это когда последовательность действий не имеет значения, чего со стримами не наблюдается.
Вот если мы строим SQL запрос, в котором есть что-то типа WHERE abc=5 AND def='a', это чисто декларативный подход - как там СУБД будет его выполнять - сначала по abc, потом по def или наоборот - а х его з, план выполнения покажет, мы только задекларировали, что нам надо.
Или где-то в CSS запишем мы
color:rgb(1,2,3)
width:50%
это декларация, как ее интерпретатор выполнит - сначала ширину установит, потом цвет, или наоборот - без разницы, все одно.
А стримы - это только краткая запись итеративного подхода, где основное "мясо" скрыто в библиотеке, только и всего. Тот же самый цикл в stream...collect, то же самое тело с фильтрами и апкейсом.
Ты о чем?
Он о том, как я понял, что лямбды под капотом - это старое старье - функциональный тип без имени, объявляемый по месту + фиксация окружения на момент вызова (как в древнем Паскале во вложенных процедурах). Paradox о "нутрях", а не "фронтальной" абстракции, насколько я его понимаю.
Отправлено 05 ноября 2017 - 03:09
Zero, у тебя какая-то концептуальная путаница.
Ты зачем-то прицепился к последовательности действий при вызове лямбд внутри filter и утверждаешь что оно имеет какое-то значение. Какое значение оно имеет? Для конечного результата оно не имеет никакого значения. Можно написать
filter(name -> name.startsWith("J")).filter(name -> name.length() > 6)
или
filter(name -> name.length() > 6).filter(name -> name.startsWith("J"))
и в конце ты получишь одно и то же, что очевидно.
Поменять место map ты естественно не можешь, потому что в этом случае ты меняешь ЧТО ты хочешь получить. Так же как в SQL есть разница между
SELECT
UPPER(some_column) as upper_some_column
WHERE
upper_some_column like 'J%'
AND
etc...;
и
SELECT
UPPER (output) from (
SELECT
some_column as output
WHERE
output like 'J%'
AND
etc...);
Ну и collect() вызывается всегда в конце чтобы сигнализировать что ты закончил формулировать ЧТО ты хочешь и теперь желаешь получить результат. Это как semicolon в SQL запросе, только в Java ты еще указываешь в каком виде вернуть результат.
Или ты считаешь, что раз мы скрыли итеративный код в библиотеку, то он таковым перестал быть?
Он - нет. Но он сидит внутри библиотеки, ты его не видишь. А твой код, который использует эту библиотеку, может уже быть декларативным, а не императивным. Возьмем SQL. Ты наверное понимаешь, что там внизу, близко к железу, он превращается в последовательность машинных команд - в императивный код. Но ты пишешь декларативный SQL. Точно так же и со стримами в Java - я пишу какой результат мне нужен - в декларативном стиле, а библиотека уже заботится о том как этот результат получить и, например, в случаях последовательного или параллельного исполнения, библиотека запускает совершенно разную последовательность императивных команд. В СУБД естественно гораздо более навороченный механизм, который берет твой запрос и генерирует query plan (по сути набор императивных команд на низком уровне), работа этого механизма зависит от наличия информации по таблицам (table statistics), что в свою очередь позволяет осмысленно переупорядочивать WHERE части запросов для оптимизации производительности. Без статистики по таблицам или неправильной статистики (случается после изменения схемы БД) оптимизатор запросов больше не может правильно переупорядочить последовательность чтений из таблиц и становится таким же глупым как стримы в Java, которые тоже ничего не переупорядочивают там где это не изменяет конечный результат.
processCollectionAsINeededIt() и вся программа будет в виде:
main()
processCollectionAsINeededIt()
end;
Что, это тоже декларативный подход? Ну, мы же задекларировали, что хотим обработать коллекцию так как нам надо.
Ну конечно. Это супердекларативный подход. Сделай то, не знаю что, но дай мне правильный, ожидаемый мной результат. Чистая декларативщина. Правда, пока компьютеры не стали сверхинтеллектуальными, возможный в реальности декларативный подход будет такой как в SQL или в Stream'ах.
Он о том, как я понял, что лямбды под капотом - это старое старье - функциональный тип без имени, объявляемый по месту + фиксация окружения на момент вызова (как в древнем Паскале во вложенных процедурах). Paradox о "нутрях", а не "фронтальной" абстракции, насколько я его понимаю.
Нет, если этот товарищ так считает, то это лишь демонстрирует его безграмотность. Естественно, ничего принципиально нового в Java-ских лямбдах с точки зрения теории нет, но практическая их реализация и то как они выглядят в байткоде отличается от использования анонимных классов. Они не являются только лишь синтаксическим сахарком. По соображениям производительности для них потребовалось менять JVM. За подробностями, см, например, https://www.infoq.co...-Under-the-Hood.
Сообщение изменено: Transhumanist (05 ноября 2017 - 03:11 )
Отправлено 05 ноября 2017 - 06:57
Transhumanist, бессоница? Второй день ночью отвечаешь
The Dark Knight
Отправлено 05 ноября 2017 - 10:55
коллеги. успокойтесь.
если я покажу свои сиськи то ты не отстанешь от них никогда, и я стану в сто раз популярнее всех баб на форуме и язык у тебя прилипнет к бороде)))) Потому что у меня очень роскошный бюст, но я ни за что не нуждаюсь, чтоб на него пялились похотливые ненасытные брюсы; // удалите сообщения с моей синей фоткой где я под феном 
, я вам другую поставлю)))
TRUST NO ONE
Отправлено 21 ноября 2017 - 02:59
Zero, у тебя какая-то концептуальная путаница.
Нет, моя позиция четко очерчена. Ты же, напротив, почему-то считаешь, что если императивный подход скрыт за фасадом библиотеки, то он перестает таковым быть. Но это не так, почему - я поясню ниже частями, отвечая на твои выпады.
Ты зачем-то прицепился к последовательности действий при вызове лямбд внутри filter и утверждаешь что оно имеет какое-то значение. Какое значение оно имеет? Для конечного результата оно не имеет никакого значения. Можно написать
filter(name -> name.startsWith("J")).filter(name -> name.length() > 6)
или
filter(name -> name.length() > 6).filter(name -> name.startsWith("J"))
и в конце ты получишь одно и то же, что очевидно.
Нет-нет-нет, я не держусь за это, это мелкая частность.
Пусть для ясности останется только один фильтр, никакой разницы - моя позиция та же. Пусть у нас будет
.filte(name->name.length() >6).map.collect.
Поменять место map ты естественно не можешь, потому что в этом случае ты меняешь ЧТО ты хочешь получить. Так же как в SQL есть разница между
....
Ну и collect() вызывается всегда в конце чтобы сигнализировать что ты закончил формулировать ЧТО ты хочешь и теперь желаешь получить результат. Это как semicolon в SQL запросе, только в Java ты еще указываешь в каком виде вернуть результат.
Не совсем. Точка с запятой и в Java будет той же, collect, насколько я понимаю имеет иную цель (могу ошибаться - не мое поле). map мы не можем поставить в иное место, потому что он работает по результатам фильтра, императивно. И collect нам указывает, что результаты предыдущих шагов (фильтр+мап) мы сливаем с некий sink, который будет у нас target коллекцией. Это вполне императивное описание.
Если бы мы имели дело с декларативным подходом, мы вызывали бы некую условную машину (как, например, Пролог машину, бразуер, читающий CSS или СУБД) и сказали бы ей следующее в некоторой форме, синтаксис не важен:
"Сделай так, чтобы была у меня target коллекция, в которой будут все элементы из изначальной коллекции, которые попадают под условие filter и эти элементы должны быть upcase'нуты".
И все. Как там эта машина будет это делать - а Х её З, это ее дело. Нам по барабану, как СУБД наш SQL запрос спланирует и исполнит, мы декларативно результат описали.
И отличие, проверка на вшивость декларативности подхода в данном случае следующее: машина, которая выполняет такой запрос (см. в кавычках выше) гипотетически может выполнить его так:
1) Скопировать всю source коллекцию в target коллекцию
2) Итерироваться по ней
3) Подходящие элементы upcase'нуть
4) Неподходящие - удалить.
5) Profit.
Да, О() может быть хуже, но не суть. Должна быть гипотетическая возможность такого развития событий. А раз мы указываем, что мы итерируемся по source а потом сливаем в target, то мы вполне себе императивно указываем алгоритм действий. Так же, как если бы напрямую писали for...if итд, только используем stream нотацию. Опять же - если я верно ее понял.
Он - нет. Но он сидит внутри библиотеки, ты его не видишь. А твой код, который использует эту библиотеку, может уже быть декларативным, а не императивным. Возьмем SQL. Ты наверное понимаешь, что там внизу, близко к железу, он превращается в последовательность машинных команд - в императивный код. Но ты пишешь декларативный SQL. Точно так же и со стримами в Java - я пишу какой результат мне нужен - в декларативном стиле
Это некорректная аналогия. Мы сравниваем в данном случае язык SQL запросов как язык и Java как язык.
Соответственно в обоих случаях есть что-то под капотом - анализатор запросов, планировщик и пр. в случае SQL или транслятор в байт-код, виртуальная машина, преобразование в машинный код и так далее. Но мы сравниваем два фасада - SQL запросы и Java. А ты пытаешься библиотеку в Java поставить на один уровень с кишками СУБД, это некорректно. Для мира SQL запросом "библиотекой" (ее аналогией) бы был, например, подзапрос.
Ну конечно. Это супердекларативный подход. Сделай то, не знаю что, но дай мне правильный, ожидаемый мной результат. Чистая декларативщина. Правда, пока компьютеры не стали сверхинтеллектуальными, возможный в реальности декларативный подход будет такой как в SQL или в Stream'ах.
Ок, давай я по шагам напишу преобразования такого кода в псевдокоде, а ты напиши, на какой же итерации код из императивного превратился в декларативный, ок? Все условно, формальные параметры - сквозные.
Раз:
func main
Collection lSource;
Collection lTarget;
<get data into Source here somehow>
for each lItem in lSource
if(length(lItem) < 6) and BeginsWith(lItem, "J")
lTarget.Add(UpCase(lItem));
end
end
Два:
Collection func processCollectionSequentially(Collection ASource)
Collection lTarget;
for each lItem in ASource
if(length(lItem) < 6) and BeginsWith(lItem, "J")
lTarget.Add(UpCase(lItem));
end
return lTarget;
end
func main
Collection lSource;
Collection lTarget;
<get data into Source here somehow>
lTarget = processCollectionSequentially(lSource);
end
Три:
LFilter = bool func(string AItem);
LProcess = string func(string AItem);
Collection func processCollectionSequentially(Collection ASource,
LFilter AFilterLambda,
LProcess AProcessLambda)
Collection lTarget;
for each lItem in ASource
if AFilterLambda(lItem)
lTarget.Add(AProcessLambda(lItem));
end
return lTarget;
end
func main
Collection lSource;
Collection lTarget;
<get data into Source here somehow>
lTarget = processCollectionSequentially(lSource,
func(
return (length(AItem) < 6)
and BeginsWith(AItem, "J")
),
func(
return upCase(AItem);
));
end
Четыре:
Модуль 1
LFilter = bool func(string AItem);
LProcess = string func(string AItem);
Collection func processCollectionSequentially(Collection ASource,
LFilter AFilterLambda,
LProcess AProcessLambda)
Collection lTarget;
for each lItem in ASource
if AFilterLambda(lItem)
lTarget.Add(AProcessLambda(lItem));
end
return lTarget;
end
Модуль 2
use Модуль 1
func СделайЗаепца()
Collection lSource;
Collection lTarget;
<get data into Source here somehow>
lTarget = processCollectionSequentially(lSource,
func(
return (length(AItem) < 6)
and BeginsWith(AItem, "J")
),
func(
return upCase(AItem);
));
end
Модуль main
func main
СделайЗаепца();
end
Нет, если этот товарищ так считает, то это лишь демонстрирует его безграмотность. Естественно, ничего принципиально нового в Java-ских лямбдах с точки зрения теории нет, но практическая их реализация и то как они выглядят в байткоде отличается от использования анонимных классов. Они не являются только лишь синтаксическим сахарком. По соображениям производительности для них потребовалось менять JVM. За подробностями, см, например, https://www.infoq.co...-Under-the-Hood.
Нет, это ты не понял. При чем тут джавовские анонимные классы и как оно выглядит в байт-коде? Речь о том, что сам подход был еще с тех времен, когда никакой Java не было. Да, я читал и смотрел лекции о Java lambdas under the hood, но не о том было сказано. Этот подход нов для Джавы только потому, что стратегия "все суть классы и ООП - пророк его" не катит всегда - приходится писать бойлерплейт как ты показал выше с Override'ами. И лямбды - это шаг к процедурному подходу (технически).
Сообщение изменено: Zero (21 ноября 2017 - 03:02 )
что?
Отправлено 21 ноября 2017 - 21:25
Сколько раз уже пытался понять программирование - дальше азов дело не идет. Азы вроде прошел - вроде более менее понятно - но чуть в сторону шаг и всё, ступор. Учил php / c sharp ... не получается. Ув. программисты, что вы можете посоветовать?
Что?
Отправлено 21 ноября 2017 - 21:50
Значит не твое.
С другой стороны, я давным давно когда начинал, так же раза 3-4 забивал и снова начинал учить, в конце концов мозг сдался.
Мужчина без женщины - всё равно, что дерево без гусеницы. © не Gra4-а, ему знакомый сказал
что?
Отправлено 21 ноября 2017 - 22:00
Значит не твое.
С другой стороны, я давным давно когда начинал, так же раза 3-4 забивал и снова начинал учить, в конце концов мозг сдался.
Сдался в плане забил или стал разбираться?
Что?
The Dark Knight
Отправлено 21 ноября 2017 - 23:11
у меня тоже раза 2-3 не получалось. а потом пошло. php говно))
если я покажу свои сиськи то ты не отстанешь от них никогда, и я стану в сто раз популярнее всех баб на форуме и язык у тебя прилипнет к бороде)))) Потому что у меня очень роскошный бюст, но я ни за что не нуждаюсь, чтоб на него пялились похотливые ненасытные брюсы; // удалите сообщения с моей синей фоткой где я под феном , я вам другую поставлю)))
Отправлено 22 ноября 2017 - 11:24
Если бы мы имели дело с декларативным подходом, мы вызывали бы некую условную машину (как, например, Пролог машину, бразуер, читающий CSS или СУБД) и сказали бы ей следующее в некоторой форме, синтаксис не важен:
"Сделай так, чтобы была у меня target коллекция, в которой будут все элементы из изначальной коллекции, которые попадают под условие filter и эти элементы должны быть upcase'нуты".
И все. Как там эта машина будет это делать - а Х её З, это ее дело. Нам по барабану, как СУБД наш SQL запрос спланирует и исполнит, мы декларативно результат описали.
И отличие, проверка на вшивость декларативности подхода в данном случае следующее: машина, которая выполняет такой запрос (см. в кавычках выше) гипотетически может выполнить его так:
1) Скопировать всю source коллекцию в target коллекцию
2) Итерироваться по ней
3) Подходящие элементы upcase'нуть
4) Неподходящие - удалить.
5) Profit.
Ок, Zero, я тебя понял (насколько это возможно ). Тогда вопрос, если я допишу несколько строк к твоему коду и он станет работать так как ты описал выше, то как ты это прокомментируешь? Ты тогда признаешь, что именно эти несколько строчек кода превратили его из императивного в декларативный?
Поставщик загробных мук
Отправлено 11 декабря 2017 - 23:01
Отправлено 12 декабря 2017 - 00:29
i = 5;
i = 6+6=12;
И последний пост-инкремент ни на что не влияет
Вначале делаю, потом думаю
The Dark Knight
Отправлено 12 декабря 2017 - 01:33
зависит от языка. могут быть разные ответы.
если я покажу свои сиськи то ты не отстанешь от них никогда, и я стану в сто раз популярнее всех баб на форуме и язык у тебя прилипнет к бороде)))) Потому что у меня очень роскошный бюст, но я ни за что не нуждаюсь, чтоб на него пялились похотливые ненасытные брюсы; // удалите сообщения с моей синей фоткой где я под феном , я вам другую поставлю)))
Отправлено 12 декабря 2017 - 14:34
даёшь холивар!int i = 5;i = ++i + i++;чему равно i?
Равно вздрючке от техлида за написание кода в таком стиле.
Поставщик загробных мук
Отправлено 12 декабря 2017 - 16:24
Transhumanist, подразумевается что тимлид умеет в код ревью
Отправлено 12 декабря 2017 - 17:27
Такое зарубить - не надо быть вообще никем. Достаточно просто быть нормальным человеком, чтоб понять, что вот так писать - самого себя в голову иметь. И другим ломать.
Вначале делаю, потом думаю
Отправлено 26 декабря 2017 - 19:04
Какой код ревью, не надо в кучу всё смешаивать. Есть такое понятие как code puzzlers на знание и понимание тонкостей языка, такая задача типичный тому пример.
Отправлено 26 декабря 2017 - 20:18
А пацаны-то не знали.
Так, а чё вообще, в каких языках (которые вообще поддерживают пре-/пост-инкременты) какие ответы-то будут? Просто интересно, у кого какие блэкджэки и шлюхи
Сообщение изменено: Дык (26 декабря 2017 - 20:18 )
Вначале делаю, потом думаю
The Dark Knight
Отправлено 27 декабря 2017 - 10:32
А пацаны-то не знали.
Так, а чё вообще, в каких языках (которые вообще поддерживают пре-/пост-инкременты) какие ответы-то будут? Просто интересно, у кого какие блэкджэки и шлюхи
Я же написал выше. Ответ зависит от языка.
если я покажу свои сиськи то ты не отстанешь от них никогда, и я стану в сто раз популярнее всех баб на форуме и язык у тебя прилипнет к бороде)))) Потому что у меня очень роскошный бюст, но я ни за что не нуждаюсь, чтоб на него пялились похотливые ненасытные брюсы; // удалите сообщения с моей синей фоткой где я под феном , я вам другую поставлю)))
Поставщик загробных мук
Отправлено 27 декабря 2017 - 11:05
The Dark Knight
Отправлено 28 декабря 2017 - 13:55
В последнее время очень активно зазывают в LHV и SWEDBANK на Java. Там что-нибудь изменилось в лучшую сторону?
если я покажу свои сиськи то ты не отстанешь от них никогда, и я стану в сто раз популярнее всех баб на форуме и язык у тебя прилипнет к бороде)))) Потому что у меня очень роскошный бюст, но я ни за что не нуждаюсь, чтоб на него пялились похотливые ненасытные брюсы; // удалите сообщения с моей синей фоткой где я под феном , я вам другую поставлю)))
Отправлено 11 января 2018 - 09:21
Кто-нибудь что-нибудь знает про InBank?
Вначале делаю, потом думаю
The Dark Knight
Отправлено 11 января 2018 - 14:46
ruby. фу. говно
если я покажу свои сиськи то ты не отстанешь от них никогда, и я стану в сто раз популярнее всех баб на форуме и язык у тебя прилипнет к бороде)))) Потому что у меня очень роскошный бюст, но я ни за что не нуждаюсь, чтоб на него пялились похотливые ненасытные брюсы; // удалите сообщения с моей синей фоткой где я под феном , я вам другую поставлю)))
Отправлено 01 февраля 2018 - 14:42
Проблема функционального программирования (которая вообще шире столь полюбившимися многим си-шарповским Лямбдам) в том что при программировании задом-наперед мы иногда упираемся в тупик, после чего программист начинает либо плодить свои методы расширения, либо громоздить классический код вперемешку с лямбдами и т.п. Как результат выходит нечто неудобочитаемое. И такого неудобочитаемого Over-дофига на любом ресурсе с исходниками, лямды вперемешку с вызовами чего-попало куда-попало.
Причина тоже понятна - писали одно, вышло другое. Надо править, правили как могли чтобы все не переписывать, что совсем уж не кашерный подход.
Я бы на Дельфи вообще не использовал подобный подход и их анонимные методы мне вообще не глянулись (хотя я субъективен) и писал бы таким образом, подо что эта среда заточена - либо классическое процедурно-ориентированное программирование, либо столь же классическое ООП. К слову любая дельфинская лапша просматривается влет и найти проблему (переписать) несложно, как и прочее классическое типа ранних версий Джавы или Си.
Да простят меня коллеги, но спор Delphi vs Java вообще лишен смысла :о))
Отправлено 10 февраля 2018 - 11:21
Добрый день.
А файл DAT можно раскрыть и прочитать?
Сколько это будет примерно стоить? А то у меня не получается.
