ну ладно, че, те функции, которые используются argsEvaluatedIn — нейтив на сишке, остальные где то порядка 5 - 10 строк каждая.

Теперь когда ты понял, что любой код должен быть где-то написан, MyOtherUtils не нужны.

public class MyUtils {
    public static int[] squared(int[] source) {
        int[] result = Arrays.copyOf(source, source.length);
        for (int i = 0; i < result.length; i++) {
            result[i] *= result[i];
        }
        return result;
    }
}

да.

Например?

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

Например У тебя может быть функция sum := method(x, if(x type == "enotherNumber") then (x + x + x) else (x + x))

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

Нет, это ты пытался меня надуть утверждая что там одна строка, а оказалось что там те функции, которые используются argsEvaluatedIn — нейтив на сишке, остальные где то порядка 5 - 10 строк каждая.

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

Например У тебя может быть функция sum := method(x, if(x type == «enotherNumber») then (x + x + x) else (x + x))

Это где-то применяется кроме как для демонстрации возможностей создания произвольных сабклассов?

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

точно также, я могу вместо map например, написать reduce, mapInPlace, sum, свой собственный метод, и это будет работать везде и всегда, выражения будут всегда единообразные, они влезут в любую функцию, типа method(list, operation, operation2, list operation(operation2)) независимо от содержимого а у тебя просто имитация, не окажется в твоей сраной либе подходящего матода, и тебе придется писать тоны твоего говна, и все это будет жить отдельной жизнью.

Везде. и не только это. Это всего лишь пример.

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

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

Везде

Можно ссылку на проект где активно используется наследование от чисел?

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

if(request.url.adress.test(/foo{{POKK&***^^%%/) && Date.day == "someday") bla-bla
if(request.url.adress.test(/foo{{POKK&***^^%%/) && Date.day == "someday") bla-bla
if(request.url.adress.test(/foo{{POKK&***^^%%/) && Date.day == "someday") bla-bla
if(request.url.adress.test(/foo{{POKK&***^^%%/) && Date.day == "someday") bla-bla
.....

а

 bla-bla (request.dispatch)

его не нужно будет писать.

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

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

Что из этого нельзя сделать на языке где нельзя наследоваться от стандартных чисел?

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

Ты уже забыл? Я же только что показал что никаких сотен строк нет. А торомозит/падает оно по причине твоих кривых рук.

В данном случае от строк. Вопрос в цене реализации. Я просто буду на ходу преобразовывать строки в объекты, и они не перестанут при этом оставаться строками. В одном месте

request = Monday with(request)
или даже
request = getSlot(Date day) with(request)

if(request.matchesRegex("foo")) request.dispatch

только что показал

ты фокус показал

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

В данном случае от строк. Вопрос в цене реализации. Я просто буду на ходу преобразовывать строки в объекты, и они не перестанут при этом оставаться строками

И какой в этом смысл? Почему этого нельзя сделать не наследуясь от строк?

ты фокус показал

Когда нихрена не знаешь - кругом одни чудеса.

Судя по выбору языков, выбор делается в сторону веба. А раз так, тогда можно выбирать JS(Node.JS). Сегодня для веба уже достаточно знать лишь JS. Использовать его на клиенте и на сервере.

Тысячи и миллионны классов копируются.

Спасибо поржал.

А как ты будешь вызывать методы, специфичные для строк? Я же показал. и даже не так, а

request do( if(matchesRegex("foo") and type = "Sunday") dispatch(sunstring("foo")))

допустим.

кругом одни чудеса.

Да и они заключаются в следующем

fu vs 30 строк на жабе

дубль2

fu vs fu = function(){30 строк на жабе}

дубль 3

fu vs fu

молодца, че, петросяна без работы оставил

А как ты будешь вызывать методы, специфичные для строк? Я же показал. и даже не так, а

Буду вызывать их на строках, в чём проблема?

fu vs 30 строк на жабе

нет, в твоём варианте было fu {хз сколько строк в стандартной либе} vs ндцать строк говнокода, что оказалось неверно для корректного сравнения.

Буду вызывать их на строках, в чём проблема?

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

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

а конкретно, когда уже руби вытеснит жабку, не говоря уж про кресты?

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

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

Нет такой проблемы, мне не нужны наследники от строк, они почему-то нужны тебе.

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

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

но проблему

То есть, по-твоему, другие языки должны решать жабапроблемы?

Достаточно того, что они не порождают проблем.

Достаточно того, что они не порождают проблем.

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

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

О да, а вот анонимус на лоре, он понимает, светоч знаний и мастер кода. Бутылки-то вчера собрал, чтоб на плавленый сырок хватило?

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

Это объектно-ориентированое программирование, ни разу не функциональное.

книжку бы почитал чем фантазиями заниматься

Io — чисто объектно-ориентированный язык, там нет никакого функционального говна.

Питон.

Io — чисто объектно-ориентированный язык

как будет угодно
вот только смотря на

List with(1,2,3) with(3,4,5) with(6,7,8) map(squared)

Попробуй написать на функциональном что то типа

l := list(1,2,3) 
l mapInPlace(+ 1)

Впечатление обманчиво, возможно синтаксические конструкции чем то похожи, не более того. Начать можно с того, что хаскель не может в суперклассы, это уже твою версию ломает в основе.

да без проблем, даже лучше сделаю

for-repl.core=> (def l (agent (list 1 2 3)))
#'for-repl.core/l
for-repl.core=> (send l (fn [l] (map #(* % 3) l)))
#object[clojure.lang.Agent 0x14ec01b2 {:status :ready, :val (3 6 9)}]
for-repl.core=> @l
(3 6 9)

ну только к синтаксису давай не придираться - уж очень нравятся мне лиспы

Впечатление обманчиво, возможно синтаксические конструкции чем то похожи, не более того. Начать можно с того, что хаскель не может в суперклассы, это уже твою версию ломает в основе.

на самом деле меня не интерисуют ни хаскель ни суперклассы
поэтому сорян если чо попутал)

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

т.е. по сути сказать нечего?)
как всегда пук в лужу?

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

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

Твой l сохранил состояние после деструктивного изменения, правильно я понял?

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

т.е. по сути сказать нечего?)
как всегда пук в лужу?

ну всё как обычно)

Ты нулевой, пойдешь в игнор.

утютю)

короче, автор, главное не учи Io. А то сойдешь с ума и будешь на людей кидаться, как aboutcard.

А если серьезно, то Java. Там ты найдешь всё, что пытается изобразить PHP на протяжении последних версий, а именно язык с нормальной статической типизацией.

могу создать класс Week и Сабклассы Sunday и прочие

Такой радости тебе и в JS достаточно будет, вместе с чудесными «фичами» вроде патчинга объектов и стандартных типов в runtime, отсутствием контроля типов и интерфейсов, короче всем тем, что aboutcard считает правильным подходом к разработке.

Такой радости тебе и в JS достаточно будет

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

r = rgba & 0xff;
    g = (rgba >> 8) & 0xff;
    b = (rgba >> 16) & 0xff;
    a = (rgba >> 24) & 0xff;

    r0 = r;
    g0 = g;
    b0 = b;
    a0 = a;

    r1 = r0;
    g1 = g0;
    b1 = b0;
    a1 = a0;

    r2 = r1;
    g2 = g1;
    b2 = b1;
    a2 = a1;

    line_buf_offs = 0;

    for (x = 0; x < width; x++) {
      rgba = src[in_offs];

Поэтому, использование JS сильно затруднено. Хотя, он, безусловно бесконечно более мощный язык нежели java, например, тем не менее.

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

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