Здравствуйте, Mr.Delphist, Вы писали:

MD> Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?
Во-первых, накой оно? На практике голые массивы по индексу вообще редко нужны. Чаще списки, мапы, деревья, в худшем случае буфер (т.е. именно что memory layout). Обход по foreach.
Во-вторых, это можно юзабельным сделать только при хорошей системе типов. Ну, допустим, есть у тебя массив [-10..10]. И тебе надо иметь функцию поиска макс эл-та в списке. Зачем этой функции два индекса? Или где-то магически переиндексироваться должно? В рантайме, с накладными расходами? Или компилятор должен это как-то магически перекодировать?
В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке.
В-четвёртых, KISS.

Здравствуйте, Ikemefula, Вы писали:

I>ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.

Здравствуйте, Cyberax, Вы писали:

I>>ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
C>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.

Имхо, от ООП реально нужно: объект с полями и методами; интерфейсы; возможность реализовывать несколько интерфейсов. Наследование объектов не нужно, только наследование интерфейсов.

Ну понятно, что желательно модификаторы видимости, но это уже, считаю, к ООП не относится, это более общая концепция модульности.

Здравствуйте, Cyberax, Вы писали:

I>>ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
C>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.

Не смеши людей. Агрегирование-делегирование-композиция-интерфейс это, например, обычный роутер веб приложения. Открой пример и посмотри сам.
Вероятно, для тебя ООП это три кита. На самом деле это необязательная модель. Вот например есть у тебя логирование — это уже ООП. Даже если ты его монадой writer реализуешь, всё равно это будет ООП.

Здравствуйте, Cyberax, Вы писали:

C>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.

Оно теснит скорее скрипты на bash и perl.

Здравствуйте, ·, Вы писали:

·>Во-вторых, это можно юзабельным сделать только при хорошей системе типов. Ну, допустим, есть у тебя массив [-10..10]. И тебе надо иметь функцию поиска макс эл-та в списке. Зачем этой функции два индекса? Или где-то магически переиндексироваться должно? В рантайме, с накладными расходами? Или компилятор должен это как-то магически перекодировать?

Ну то есть инженеграм лень изучать системы типов. В Аде83 была индексация хоть по enum, и сейчас она есть, работает со скоростью Си.

Здравствуйте, Слава, Вы писали:

C>>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.
С>Оно теснит скорее скрипты на bash и perl.
Kubernetes — 1.5 миллиона строк.

Здравствуйте, Ikemefula, Вы писали:

I>Вероятно, для тебя ООП это три кита. На самом деле это необязательная модель. Вот например есть у тебя логирование — это уже ООП. Даже если ты его монадой writer реализуешь, всё равно это будет ООП.
ООП — это таки весь стиль программирования. Т.е. сокрытие реализации, доступ к внутренним данным объектов через методы, наследование реализации и т.п. Это всё, к счастью, начинает умирать. Даже в самых ударенных на ООП-голову языках как Java.

Элементы ООП оказались полезны, да. Но практически это только интерфейсы и группировка функций в виде методов классов.

Здравствуйте, Cyberax, Вы писали:

I>>Вероятно, для тебя ООП это три кита. На самом деле это необязательная модель. Вот например есть у тебя логирование — это уже ООП. Даже если ты его монадой writer реализуешь, всё равно это будет ООП.
C>ООП — это таки весь стиль программирования. Т.е. сокрытие реализации, доступ к внутренним данным объектов через методы, наследование реализации и т.п. Это всё, к счастью, начинает умирать. Даже в самых ударенных на ООП-голову языках как Java.

Это никакой не стиль, а парадигма. Только направлена не на вычисления, на структуру решения. В го сокрытие реализации есть, а традиционного наследования — нет. Это не страшно и непринципиально для ООП. Композиция гораздо важнее.
ООП в Джава сильно олдскульное. С тех пор много чего поменялось. Даже дотнет в этом плане староват. В Го — более современное. Как только ГО вытеснит дотнет с джавой по количеству нового кода, можно будет посмотреть, чего же в него натолкают к тому времени

C>Элементы ООП оказались полезны, да. Но практически это только интерфейсы и группировка функций в виде методов классов.

От агрегирования, делегирования, композиции отказаться не получится Смотри внимательно на роутер в примера по Го — он агрегирует хандлеры и делегирует им обработку каждого роута. Как только ты начнешь внедрять в библиотеку вещи, что бы облегчить сложные задачи, ООП само по себе попрёт изо всех щелей.

upd: похоже, что уже давно попёрло https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/node/graph.go
Не вижу отличий от обычного ООП

Вот еще
https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/node/graph_populator.go

    if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) {
        nodes.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{
            AddFunc:    g.addNode,
            UpdateFunc: g.updateNode,
            DeleteFunc: g.deleteNode,
        })
    }

Собственно, товарищи идут ровно тем же путём, что и Джаваскрипт с Тайпскриптом

Вот пример — стейтфул модуль. Хватит ли дисциплины разработчикам не упороться?

// https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/auth/authorizer/node/node_authorizer.go
var (
    configMapResource = api.Resource("configmaps")
    secretResource    = api.Resource("secrets")
    pvcResource       = api.Resource("persistentvolumeclaims")
    pvResource        = api.Resource("persistentvolumes")
    vaResource        = storageapi.Resource("volumeattachments")
    svcAcctResource   = api.Resource("serviceaccounts")
    leaseResource     = coordapi.Resource("leases")
    csiNodeResource   = storageapi.Resource("csinodes")
)

А вот еще пример неооп

func (r *NodeAuthorizer) Authorize(ctx context.Context, attrs authorizer.Attributes) (authorizer.Decision, string, error)

А вот и классика — метод для доступа к данным, который по твоим словам, куда то делся

func (r *NodeAuthorizer) authorizeStatusUpdate(nodeName string, startingType vertexType, attrs authorizer.Attributes) (authorizer.Decision, string, error) {
    switch attrs.GetVerb() {

...

    return r.authorize(nodeName, startingType, attrs)
}

"сокрытие реализации, доступ к внутренним данным объектов через методы" @ Cyberax

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, CreatorCray, Вы писали:

CC>>Здравствуйте, AlexRK, Вы писали:

ARK>>>Так это ж наоборот круто.
CC>>Шоп да так ж нет!

MD>Кстати, вот удивляло: в Паскале самых ранних версий (т.е. даже не Delphi ещё) можно было делать индексы хоть отрицательными, хоть как. Просто пишешь "x: array[-10..10] of integer" и готово, получаешь массив на 21 элемент. Таким образом, индексацию можно было получить согласно задаче, а не исходя из memory layout, как это традиционно делается.

MD>Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?

В .NET есть поддержка, но в C# с таким работать чуть сложнее чем с обычными массивами.

using System;
using System.Linq;

namespace ConsoleApp8
{
    class Program
    {
        static void Main(string[] args)
        {
            // -10 .. 9
            Array data = Array.CreateInstance(typeof(int),
                new int[] { 20 },
                new int[] { -10 });


            Console.WriteLine(data.GetLowerBound(0));
            Console.WriteLine(data.GetUpperBound(0));

            for (int i = -10; i < 10; i++)
            {
                data.SetValue(i, i);
            }

            Console.WriteLine(string.Join(", ",
                Enumerable.Range(data.GetLowerBound(0), data.GetUpperBound(0)).Select(i => data.GetValue(i))));
        }
    }
}

-10
9
-10, -9, -8, -7, -6, -5, -4, -3, -2

Здравствуйте, Cyberax, Вы писали:

C>>>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.
С>>Оно теснит скорее скрипты на bash и perl.
C>Kubernetes — 1.5 миллиона строк.

Строк на Го. Т.е. на нормальных языках полторы тыщи будет.

Здравствуйте, ·, Вы писали:

·>В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке.

Оптимизация страдает. Этот shift будет вызываться каждый божий раз.


·>В-четвёртых, KISS.

Это и есть KISS.

Здравствуйте, vdimas, Вы писали:

V>·>В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке.
V>Оптимизация страдает. Этот shift будет вызываться каждый божий раз.
Во-первых, даже если такое встроено в язык тоже никакой оптимизации не гарантирует. Во-вторых, что такая проблема была только в ранних версиях Паскаля. Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз.

Здравствуйте, D. Mon, Вы писали:

С>>>Оно теснит скорее скрипты на bash и perl.
C>>Kubernetes — 1.5 миллиона строк.
DM>Строк на Го. Т.е. на нормальных языках полторы тыщи будет.
Удар ниже пояса, однако.

Здравствуйте, ·, Вы писали:

V>>·>В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке.
V>>Оптимизация страдает. Этот shift будет вызываться каждый божий раз.
·>Во-первых, даже если такое встроено в язык тоже никакой оптимизации не гарантирует.

Это слишком общие рассуждения.
Некий трюк оптимизации либо доступен (напр., через распространение констант), либо нет.
В твоём варианте сразу нет.


·>Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз.

Забыл повторить про "плёвое дело на любом современном языке.". ))
Это возможно лишь в тех языках, где числовые константы могут быть частью параметризации типа.

Здравствуйте, vdimas, Вы писали:

V>>>Оптимизация страдает. Этот shift будет вызываться каждый божий раз.
V>·>Во-первых, даже если такое встроено в язык тоже никакой оптимизации не гарантирует.
V>Это слишком общие рассуждения.
V>Некий трюк оптимизации либо доступен (напр., через распространение констант), либо нет.
V>В твоём варианте сразу нет.
Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован. А ты зуб даёшь что в ранних версиях паскаля эта оптимизация была? Повторюсь, наличие фичи не означает никакой оптимизации. Это ортогональные понятия. Зачем ты всё мешаешь в кучу — непонятно.

V>·>Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз.
V>Забыл повторить про "плёвое дело на любом современном языке.". ))
V>Это возможно лишь в тех языках, где числовые константы могут быть частью параметризации типа.
Верно. Там где парятся о перформансе, там такой трюк проворачивается. В C++ будут шаблоны с числами, в java почти наверняка сработает JIT. А скорее всего, даже лишний +- константы не будет оказывать никакого измеримого влияния на реальный код. Да ещё на самом деле ещё бы найти такой реальный код, в котором возникнет надобность такой фичи. В общем, мы как-то плавно свернули с обсуждения фич языка к перформансу...

Здравствуйте, ·, Вы писали:

V>>Некий трюк оптимизации либо доступен (напр., через распространение констант), либо нет.
V>>В твоём варианте сразу нет.
·>Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован.

Было дано необходимое условие — распространение констант.
Если ты не согласен с этим условием, аргументируй, плиз.


·>А ты зуб даёшь что в ранних версиях паскаля эта оптимизация была?

1. Попытка подмены тезиса, т.е. признание слабости своей позиции. ))
2. К тому же, ты не указал, о какой реализации речь, их же было около десятка независимых.


·>Повторюсь, наличие фичи не означает никакой оптимизации.

Повторение подмены тезиса.


·>Это ортогональные понятия. Зачем ты всё мешаешь в кучу — непонятно.

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


V>>·>Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз.
V>>Забыл повторить про "плёвое дело на любом современном языке.". ))
V>>Это возможно лишь в тех языках, где числовые константы могут быть частью параметризации типа.
·>Верно. Там где парятся о перформансе, там такой трюк проворачивается. В C++ будут шаблоны с числами, в java почти наверняка сработает JIT.

Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл.

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

Здравствуйте, vdimas, Вы писали:

v> V>>В твоём варианте сразу нет.
v> ·>Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован.
v> Было дано необходимое условие — распространение констант.
v> Если ты не согласен с этим условием, аргументируй, плиз.
Условие дано было тобой, притом в качестве примера. Зачем это условие было дано и какое это имеет отношение к начальному вопросу — мне непонятно.

v> ·>А ты зуб даёшь что в ранних версиях паскаля эта оптимизация была?
v> 1. Попытка подмены тезиса, т.е. признание слабости своей позиции. ))
v> 2. К тому же, ты не указал, о какой реализации речь, их же было около десятка независимых.
Нет, это попытка вернуть тебя обсуждаемому вопросу: "в Паскале самых ранних версий можно было делать индексы хоть отрицательными ... Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?"

v> ·>Это ортогональные понятия. Зачем ты всё мешаешь в кучу — непонятно.
v> Если не видишь, что пытаешься одно утверждение заменить другим, то вовсе пичаль.
Ты сам с собой споришь опять. Я тебе не мешаю?

v> ·>Верно. Там где парятся о перформансе, там такой трюк проворачивается. В C++ будут шаблоны с числами, в java почти наверняка сработает JIT.

v> Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл.
Аналогом обсуждаемого x: array[-10..10] of integer как раз и будет new ShiftedArray(-10, 10) т.е. приватные финальные поля, константы везде, в полный рост. А тебя опять куда-то понесло.

v> Т.е., может себе и сработает для временного объекта на стеке, но коллекции чаще используют в других сценариях — в кач-ве полей долгоживущих объектов.
Да это вообще бессмысленный спор. Пока никто так и не привёл даже примера использования такой конструкции, который можно было бы пообсуждать. А рассуждать о перформансе произвольного кода вещь неблагодарная.

Здравствуйте, ·, Вы писали:

v>> V>>В твоём варианте сразу нет.
v>> ·>Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован.
v>> Было дано необходимое условие — распространение констант.
v>> Если ты не согласен с этим условием, аргументируй, плиз.
·>Условие дано было тобой

Мной лишь озвучено вслух, а дано самой спецификой задачи.


·>притом в качестве примера.

Набор слов. ))
Мы всё еще говорим об оптимизации арифметических операций?


·>Зачем это условие было дано и какое это имеет отношение к начальному вопросу — мне непонятно.

О! Уже начальный вопрос!
Так сразу и скажи — имею желание слить, не знаю как. ))

Я отвечал на кое-какое твоё конкретное утверждение, освежи, плиз.


v>> Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл.
·>Аналогом обсуждаемого x: array[-10..10] of integer как раз и будет new ShiftedArray(-10, 10) т.е. приватные финальные поля, константы везде, в полный рост.

Ты точно на джаве пишешь?
Какой в опу "в полный рост", если final поле меняется через рефлексию?

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


·>А тебя опять куда-то понесло.

Ага, в ликбез.


v>> Т.е., может себе и сработает для временного объекта на стеке, но коллекции чаще используют в других сценариях — в кач-ве полей долгоживущих объектов.
·>Да это вообще бессмысленный спор. Пока никто так и не привёл даже примера использования такой конструкции, который можно было бы пообсуждать. А рассуждать о перформансе произвольного кода вещь неблагодарная.

Ясно. ))
Неожиданно смачный слив...

Здравствуйте, vdimas, Вы писали:

V>Мной лишь озвучено вслух, а дано самой спецификой задачи.
Какой задачи? Цитату плз.

V>Мы всё еще говорим об оптимизации арифметических операций?
Не знаю о чём говорите вы, но я об этом даже не начинал говорить.

V>Я отвечал на кое-какое твоё конкретное утверждение, освежи, плиз.
Освежи.

v>>> Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл.
V>·>Аналогом обсуждаемого x: array[-10..10] of integer как раз и будет new ShiftedArray(-10, 10) т.е. приватные финальные поля, константы везде, в полный рост.
V>Ты точно на джаве пишешь?
Не знаю, просто кнопки давлю, а там уж что получится. Но точно могу сказать, что ты на джаве не пишешь.

V>Какой в опу "в полный рост", если final поле меняется через рефлексию?
Не неси такой бред, тебя же люди читают.

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

The specification allows aggressive optimization of final fields

и далее JLS §17.5.3.

Ты хоть гугли прежде чем заявлять очередную глупость
https://stackoverflow.com/questions/34829470/change-final-value-compiled-by-jit