Программирование[9]

[nobodies]

GoldRobot написал 23 минуты назад:

Короче, пора видимо подводить черту вашего спора.

Кант, сколько джастдуитов?

Индекс, а у тебя?

А сколько у родителей джастдуита джастдуитов

[Just.Doit]

Index написал 1 час назад:

GoldRobot написал 1 час назад:

Короче я верно понимаю, что местные джависты настаивают на том, что бы 4 строчки кода выносились в отдельный класс с одним методом?

Я верно понимаю, что местные долбоебы искажают суть спора?

 

Если у тебя такая хуйня

        List<String> list1 = new ArrayList<>();
        List<String> list2 = new ArrayList<>();
        List<String> list3 = new ArrayList<>();
        Function<String, String> function = o -> {
            list1.add(o);
            list2.add(list1.toString());
            return list2.toString();
        };
        for (int i = 0; i < 100; i++) {
            String apply = function.apply(String.valueOf(i));
            list3.add(apply);
            i += apply.length();
        }

а по словам Канта у него подобная хуйня, лямбда, стейт, вызовы в цикле.

То перепиши в человеческий вид. Это основные мои требования. Лямбды не для того делались, чтобы ими делать говнокод.

ну во 1х тут без лямбды "говнокод" потому что мутабельные коллекции. перепиши на имутабельные

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

 

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

Изменено 7 июля 2020 пользователем Just.Doit

[Index]

Kant написал 29 минут назад:

простой вопрос

как ты собираешься делать юнит тест на приватный метод?

вот напиши мне просто класс с приватным методом и ебаный юниттест, который его вызывает с разными параметрами

Есть много путей. расположу по убыванию правильности

1 путь, не тестировать приватные методы. (мой любимый) А если у тебя возникает задача протестировать приватный метод, то возможно он

Скрытый текст

сука ты тупая тебе блять 3 раза уже писал

обладает достаточной респонсобилити, для вынесения в отдельный класс.

2 путь, ослабить ограничение области видимости метода и повесить аннотацию @VisibleForTesting 

3 путь, заюзать рефлекшоны (самый плохой)

 

Я не понимаю почему ты дебил ссылаешься на эту хуйню, задаешь мне очевидные вопросы

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

Just.Doit написал 1 минуту назад:

ну во 1х тут без лямбды "говнокод" потому что мутабельные коллекции. перепиши на имутабельные

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

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

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

[Just.Doit]

дак циклов быть не должно. должны быть мапинги коллекций, стримов, списков и тд. 

т.е. лучше Range(from = 1,  to = 100, step = 1).map( i => ... )

[DZappa]

Ребят, как добавлять новые либы в jboss сервак? В jboss modules верно? А module.xml вручную что ли писать или как?? Я НЕНАВИЖУ ЭТОТ ЖБОСС ПОЧЕМУ ТАК СЛОЖНО ПОЧЕМУ НЕДОСТАТОЧНО ДОБАВИТЬ ЛИБЫ В ПРОЕКТ А ЕЩЕ НАДО ДОБАВЛЯТЬ В ЖБОСС???

[UglyBastard]

Just.Doit написал 23 минуты назад:

дак циклов быть не должно. должны быть мапинги коллекций, стримов, списков и тд. 

т.е. лучше Range(from = 1,  to = 100, step = 1).map( i => ... )

Так а если step не 1

Если степ меняется каждый раз по-разному, как в примере выше 

[nobodies]

@Just.Doit ты же тимлид скалист в компании топ5 россии?

[E1azor]

Index написал 4 часа назад:

Хуй знает в каком мире вы живете, если вам сложно вынести бизнес логику в отдельный именованный метод. Это проще читать, проще рефакторить, проще тестировать и в целом безопаснее.

тут сыглы

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

  

Kant написал 2 часа назад:

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

пусть у тебя кнопка "решить задачу"

а под ней 10000 приватных методов

ты опять обосрался

 

[Just.Doit]

besteady написал 19 минут назад:

Just.Doit написал 48 минут назад:

дак циклов быть не должно. должны быть мапинги коллекций, стримов, списков и тд. 

т.е. лучше Range(from = 1,  to = 100, step = 1).map( i => ... )

Так а если step не 1

Если степ меняется каждый раз по-разному, как в примере выше 

опиши мне бизнес-задачу и я разобью её на ФП примитивы

там синтетика не имеющая смысла

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

PS: речь идет про кейсы не критичные к оптимизации. для оптимизаций там треш и угар начинается

nobodies написал 13 минут назад:

@Just.Doit ты же тимлид скалист в компании топ5 россии?

незнаю что за топ5

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

Изменено 7 июля 2020 пользователем Just.Doit

[UglyBastard]

Just.Doit написал 11 минут назад:

опиши мне бизнес-задачу и я разобью её на ФП примитивы

там синтетика не имеющая смысла

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

[Just.Doit]

besteady написал 10 минут назад:

Just.Doit написал 24 минуты назад:

опиши мне бизнес-задачу и я разобью её на ФП примитивы

там синтетика не имеющая смысла

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

допустим метка это enum

enum Mark {

 A

B

C

D

 

 val set = Set(A, B, C, D)

}

 

class MarkedEntity {

 mark: Mark 

}

Допустим "обработка" это effectfulProcessing(markedEntity)

 

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

 

В скале это бы выглядело так

markedEntitiesList

  .groupBy(_.mark) // здесь мы объединяем все объекты с одной и той же меткой, на выходе получаем набор таплов (mark, entitiesWithSameMarkList)

  .map { case (mark, entitiesWithSameMarkList) => entitiesWithSameMark.head } // здесь мы берем первый элемент коллекции из коллекции с одинаковыми метками

  .foreach { effectfulProcessing(_) } // здесь мы применяем процессинг для отобранных объектов с гарантированно уникальными метками

 

[UglyBastard]

Just.Doit написал 4 минуты назад:

besteady написал 30 минут назад:

Just.Doit написал 44 минуты назад:

опиши мне бизнес-задачу и я разобью её на ФП примитивы

там синтетика не имеющая смысла

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

допустим метка это enum

enum Mark {

 A

B

C

D

 

 val set = Set(A, B, C, D)

}

 

class MarkedEntity {

 mark: Mark 

}

Допустим "обработка" это effectfulProcessing(markedEntity)

 

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

 

В скале это бы выглядело так

markedEntitiesList

  .groupBy(_.mark) // здесь мы объединяем все объекты с одной и той же меткой, на выходе получаем набор таплов (mark, entitiesWithSameMarkList)

  .map { case (mark, entitiesWithSameMarkList) => entitiesWithSameMark.head } // здесь мы берем первый элемент коллекции из коллекции с одинаковыми метками

  .foreach { effectfulProcessing(_) } // здесь мы применяем процессинг для отобранных объектов с гарантированно уникальными метками

 

ну ладно

я все равно думаю, что фп много где не заменит просто цикл, но щас что-нибудь не придумаю 

[E1azor]

то есть нужно весть список перелапачивать вместо простого прохода по списку в цикле ?

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

[Just.Doit]

это для простого и неоптимизированного варианта.

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

но я вначале оговорился что ФП стиль часто это не про оптимизации, а про бизнес правила записанные легкочитаемо.

но даже если так, можно и на ФП это сделать оптимально

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

 

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

 

либо это решается рекурсией

def recursionStep(meListTail, remainingMarks): List[MarkedEntity] {

  remainingMarks match {

    case EmptyList => EmptyList

    case (currentMark :: tailMarks) =>

      val (objectWithCurrentMark, meListTail) = list.dropWhile(!_.mark == currentMark)

      List(objectWithCurrentMark) ++ recursionStep(meListTail ,tailMarks)

}

recursionStep(markedEntitiesList, Mark.set)

 

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

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

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

 

E1azor написал 22 минуты назад:

то есть нужно весть список перелапачивать вместо простого прохода по списку в цикле ?

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

жрешь говно ты, когда пишешь мутабельную хуйню

здесь стройность

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

E1azor написал 22 минуты назад:

нужно весть список перелапачивать

почитай про иммутабельные списки и оптимизации в СТД

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

 

но опять же. если счет идет на наносекунды и такты процессора - можешь сразу выкидывать почти все ФП. я сразу сказал что ФП не про код который нужно сильно оптимизировать

Изменено 7 июля 2020 пользователем Just.Doit

[Index]

E1azor написал 11 минут назад:

то есть нужно весть список перелапачивать вместо простого прохода по списку в цикле ?

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

Так у джастдуита и есть один проход, хз как в скале но если так же написать на стримах то будет ровно o(n)

 

[PochtiKakLoda]

  java code, шок

 

interface LoopableAction<T> {
    void execute(T index);
}

abstract class LoopIterator<T> {

    protected T currentValue;
    protected T maxValue;
    protected T step;

    LoopIterator(T initialValue, T maxValue, T step) {

        this.currentValue = initialValue;
        this.maxValue = maxValue;
        this.step = step;
    }

    abstract void incrementByStep();
    abstract boolean hasReachedEnd();

    public T getCurrentValue() {
        return currentValue;
    }
}


interface StepLoop<T, T1 extends LoopIterator<T>> {
    void runLoop();
}


class ForLoop<T, T1 extends LoopIterator<T>, T2 extends LoopableAction> implements StepLoop<T, T1> {

    private T1 iterator;
    private T2 action;

    ForLoop(T1 iterator, T2 action) {
        this.iterator = iterator;
        this.action = action;
    }

    @Override
    public void runLoop() {

        while (!iterator.hasReachedEnd()) {

            action.execute(iterator.getCurrentValue());
            iterator.incrementByStep();
        }
    }
}


class IntLoopIterator extends LoopIterator<Integer> {

    IntLoopIterator(Integer initialValue, Integer maxValue, Integer step) {

        super(initialValue, maxValue, step);
    }

    @Override
    void incrementByStep() {
        currentValue += step;
    }

    @Override
    boolean hasReachedEnd() {
        return currentValue >= maxValue;
    }
}


class StepLoopAction implements LoopableAction<Integer> {

    @Override
    public void execute(Integer index) {

        System.out.println(index);
    }
}

public class Main {

    public static void main(String[] args) {

        StepLoopAction action = new StepLoopAction();
        IntLoopIterator iterator = new IntLoopIterator(0, 20, 1);
        ForLoop<Integer, IntLoopIterator, StepLoopAction> forLoop = new ForLoop(iterator, action);

        forLoop.runLoop();
    }
}

 

 

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

[Index]

PochtiKakLoda написал 2 минуты назад:

Пользуйтесь

Тестами покрой, тогда заберу

[Just.Doit]

PochtiKakLoda написал 10 минут назад:

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

я если честно не понял какую задачу ты решал и на какой пост это был ответ и как относится к дискуссии выше

Index написал 11 минут назад:

E1azor написал 26 минут назад:

то есть нужно весть список перелапачивать вместо простого прохода по списку в цикле ?

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

Так у джастдуита и есть один проход, хз как в скале но если так же написать на стримах то будет ровно o(n)

 

самый простой способ - не ленивый

в джаве стримы ленивые, поэтому будет 1 проход

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

 

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

Изменено 7 июля 2020 пользователем Just.Doit

[E1azor]

Just.Doit написал 44 минуты назад:

либо это решается рекурсией

хорошее решение, на пятёрку

 

Just.Doit написал 44 минуты назад:

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

чел, тут речь про сравнение O(n) в любом случае vs O(n) в худшем случае и O(1) в лучшем случае

какие нахуй мутабельности 

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

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

 

о5 же, тут речь не о тактах а о O(n) vs O(1)..O(n), не надо тут хуйню нести

Just.Doit написал 44 минуты назад:

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

сотку джастдуитов?

скидываем код доверенному лицу, он проверяет (есть 1 попытка)

у кого производительнее, тому дАлары

набор тестов известен заранее

го?

Изменено 7 июля 2020 пользователем E1azor

[Drakonian]

намечается заруба