Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

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

V>>>Я собеседовал десятки, если не больше сотни в разные годы.
V>>>И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей.
S>>Есть какие-то объективные данные?

V>Уровень владения технологиями, технический кругозор.
V>В общем, всё, что можно выяснить на собеседовании.

S>>Без них это так - трендёж о том, как раньше девки были краше.

V>Трындёж - это не иметь возможности сравнить претендентов из разных эпох, но делать заявления.

V>>>И дело не в уровне программистов, дело кое в чём катастрофическом другом - профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.
S>>:) 
S>>Угу. Я закончил школу в 1993 году. Из параллели в 50 человек в программирование пошло двое с половиной.

V>Наверно потому что им было интересно и до ВУЗ-а.

S>>И сейчас успеха в программировании добивается примерно 1 из 20.

V>Верно, [i]сейчас[/i] вменяемых 1-2 человека из выпускаемой группы ВУЗ-а в 20+ человек.
V>Я так и говорил, а ты споришь.

V>Зато у нас из группы примерно треть достаточно успешны, т.е. примерно как эти 1-2 сегодня.
V>И так же из других групп в потоке и еще на 2-х родственных специальностях.

S>>То, что теперь [i]пытаются[/i] идти в программирование 15 из 20, общей картины никак не меняет.

V>Никто не говорил о том, что сейчас в IT стало меньше грамотных людей.
V>Говорят, что их [i]доля[/i] резко упала.
V>Т.е. резко упала средняя температура по больнице.

V>А так-то вероятнее всего обратное, грамотных в абсолютном выражении могло стать больше из-за того, что в IT стали идти "все подряд" (по крайней мере у нас, в экс-СССР), т.е. вполне могут "раскрываться" как специалисты те люди, которые в 90-х не пошли бы учиться на программиста. :xz:

V>А сейчас пошли и у них всё стало получаться, "загорелись" профессией и всё в этом роде.

V>Но это всё неспособно компенсировать всё более возрастающий поток "балласта".
V>И этот "балласт" уже давно и серьёзно влияет на индустрию.

V>Разговоры про "планку входа" у нас шли вовсю шли уже в первой половине нулевых. :)))
V>Я не могу себе представить эти разговоры в твоём 93-м, потому что за пределами требуемой на тот момент "планки входа" этих людей просто не было в профессии - они получали "корочку", но занимались другой деятельностью.

V>>>А с чем ты сравниваешь?
S>>С девяностыми.

V>Ты не ответил на вопрос.
V>Ты ж учился не на IT, откуда у тебя статистика по однокурсникам, учившимся на IT?

S>>Ну, и с тем, какие программы и какими программистами писались в 80х.

V>Отож, 90% нынеших программистов принципиально неспособны писать те программы.
V>Думаю, конкретно ты был бы способен, но тебе пришлось бы многое пересмотреть из нынешних своих представлений.
V>Ну и прокачать некоторые навыки, например, внимательность и объективность.

S>>У меня инсайд из НИИ Автоматизированных Систем - типичное учреждение промышленного программирования. 
S>>Уверяю вас: никакого "любопытства", никаких "исследователей". Совершенно простые смертные. Тётеньки, которые писали унылые программы на фортране.

V>И они получают свои 5-10 тыс $$ в месяц, поэтому сидят там? ))
V>Или там остались только те, кто не способен столько получать?

V>>>И в насколько разные это были годы?
S>>Лично я - с конца 90х и до сих пор.

V>Лично я обратил внимание на проблему уже в 2002-м году на собеседованиях.
V>Заметным потоком пошли претенденты из разряда "да вы издеваетесь!", пока не понял, что это такая новая реальность.
V>В моё время подобные ребята даже не рыпались. :xz:
V>А тут нагло ходят на собеседования.

V>Я не могу представить себе подобное в других областях, где требуются определённые непростые навыки.
V>Например, придти устраиваться танцором в балет, но растяжки нет, классика хромает, прыгучесть нулевая...
V>Решат, что чел просто прикалывается. ))

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

V>>>Проблема примерно в следующем - увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а.
S>>У нас и в 100 раз можно было больше, т.к. специальности не преподавали.
V>>>Сейчас [i]доля[/i] таких студентовв разы ниже, дай бог 1-2 на группу.
S>>Их всегда и было 1-2 на группу.

V>Это в твоей непрофильной специальности из группы 1-2 любопытсвовали в IT, оттуда статистика? ))
V>Вообще странно, что ты сразу не пошёл на интересующую тебя специальность. :xz:

S>>Если в одной группе окажется 3-4, то в другой будет 0-1.

V>На IT-специальностях так не было, разумеется.
V>Специальность была нифига не престижная, туда люди обычно знали, зачем шли.
V>За вычетом буквально нескольких, которые непонятно как в этой специальности оказались.

V>Мне проще вспомнить тех, кому специальность была не интересна и кто к окончанию ВУЗ-а был от неё далёк, чем наоборот.
V>В нашей группе было "совсем сильных" 5 человек и еще десяток с лишним достаточно вменяемых, включая двух девушек.
V>Когда искал себе людей на проект когда-то (нужно было достаточно много людей), то расчитывал хотя бы на вменяемых.

V>Что касается девочек - им системное программирование даётся объективно тяжелей, но многие грамотные девочки нашли себя в прикладном направлении, в 1C, и неплохо себя чувствуют.
V>Из одногруппниц - руководитель отдела 1С крупного поставщика решений, еще одна владелица-руководитель собственного такого предприятия помельче.

V>>>И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас?
S>>Конечно есть выборка.

V>Та не мог твой ВУЗ быть совсем отсталым, даже в пик развала в 93-м.
V>Просто у тебя выборка по непрофильной специальности.

V>>>Чел попытался присвоить себе "ошибку", которая до него была уже "сделана" эдак тысячекратно, например, тот же nil в Lisp.
S>>Да, с самомнением у вас всё хорошо. Хоар, оказывается, тупой - сам не знает, что сделал. И то, что вы nil в lisp не отличаете от NULL в Алголе - тоже плохо.

V>Оба на!
V>Пошёл юмор! ))

V>В Lisp и Algol абсолютно идентичные nil, никакого NULL в Algol нет, RTFM!
V>И распространённой практикой в те годы были списки на манер лисповых - cons/car-cdr.

V>Защита от nil всегда через проверки, что в Lisp, что в Algol, безальтернативно.

V>Далее.
V>Lisp не в вакууме жил, решал в т.ч. реальные задачи.
V>В том числе обращался к низлежащим АПИ и точно так же мог спровоцировать проходы по памяти.

V>Абсолютно идентично это было и в Algol.
V>Ответственность по-прежнему лежала на программисте - проверил ли он аргументы перед вызовом низлежащих опасных вызовов или нет.
V>Разумеется, идущие в поставке стандартные библиотеки обоих языков проверяли аргументы, в т.ч. на nil, т.е. были безопасны как в Lisp, так и в Algol, но речь не о стандартных библиотеках, верно?

V>Речь о пространстве допустимых ошибок.
V>В Лиспе вообще много чего проверять надо было, чтобы программа не улетела не туда в своём исполнении. ))
V>Таки, сильно динамический язык.

V>Ну и, тот же Лисп и им подобные языки тоже на чём-то писать надо - не всё же на асме?

V>Просто Хоар реально загоняет, я же приводил выдержки:
V>[q]
V>Ошибка уродливее, чем обратная косая черта в Windows
V>[/q]
V>Ну какая еще Windows, хосподя...
V>Это из DOS. 
V>А там из CP-M.
V>В 70-х годах Хоар об этом знал хорошо, но сейчас забыл, увы, поэтому несёт тихий бред.

V>Как думаешь, какой чертой пользовался сам Хоар приличную часть своей карьеры еще до всяких Windows? ))

V>>>Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк.
S>>Ок, самовосхваление кончилось. Пошёл чистый, незамутнённый бред. IoC и функциональные языки соотносятся примерно никак.

V>Оба на, юмор продолжается! ))

V>В общем, функциональные языки целиком на парадигме IoC живут.
V>Прямо начиная с Lisp.
V>Сам термин IoC из объектно-ориентированной среды, я его использовал сугубо удобства ради.
V>В Алгол68 ф-ии тоже поддерживаются как первоклассные типы, если что.

S>>Нормальная альтернатива - это собственно выразимость требования непустоты ссылки в терминах системы типов.

V>Я тебе заранее на это уже отвечал - смотри как это обыгрывается в функциональных языках или в том же Kotlin, т.е. в языках, где присутствуют исключения.
V>В той версии Алгола не было исключений и не было первоклассных ф-ий.
V>Он появились в Алгол68.

V>Поэтому - никак от слова совсем.

V>В общем, ты сначала прикинь хотя бы минимально, как всё это обыграть для решения реальных задач.

V>Далее.
V>Если в языке есть возможность описывать пользовательские типы, выбрасывать и перехватывать исключения, переопределять операторы и вводить алиасы типов (как typedef в С/С++), то проблема упрощается.

V>У нас прямо в боевых проектах на С++ из базовой нашей библиотеки используется:
V>[ccode]
V>typedef NotNull<SomeType> SomeTypeRef;

V>void someFunc(SomeTypeRef arg) { ... }
V>[/ccode]

V>Реализация NotNull тривиальна в единицы строк, а используется широко:
V>[ccode]
V>template<typename T>
V>class NotNull {
V>    T * ptr;

V>public:
V>    NotNull(const NotNull<T> & other)
V>        : ptr(other.ptr) {}

V>    explicit NotNull(T * other) 
V>        :  ptr(other)  
V>    {
V>        if(!other) 
V>            throw std::invalid_argument(...);
V>    }

V>    T* operator->() { return ptr; }

V>    T& operator*() { return *ptr; }
   
V>    ...
V>};
V>[/ccode]

S>>Колбек тут совершенно ни при чём - в нормальной системе типов у меня nullable reference отличается от non-nullable reference, и это всё статически проверяется.

V>Это, как раз, самая простая часть, не вызывающая сложностей.

V>У меня выше тоже SomeTypeRef статически отличается от SomeType*.
V>И никаких дополнительных фич языка не потребовалось.

V>А теперь давай про интероперабельность nullable и non-nullable типов.
V>Вот проверь статически Optional<T*> без IoC или исключений. ))
V>[ccode]
V>template<typename T>
V>class Optional;

V>typedef Optional<SomeType> SomeTypePtr;

V>template<typename T>
V>class Optional<T*> {
V>    T * ptr;

V>public:
V>    // ========== для исключений ==========
V>    explicit operator bool() const { return !!ptr; }

V>    operator NotNull<T>() const {
V>        if(T * p = ptr)
V>            return NotNull<T>(p);    // здесь лишняя проверка нивелируется

V>        throw std::logic_error(...);
V>    }
V>    // ====================================

V>    // =========== для IoC ================
V>    template<class Some, class None>
V>    void dispatch(Some some, None none) {
V>        if(T * p = ptr)
V>            some(p);
V>        else
V>            none();
V>    }
V>    // ====================================
V>};

V>void func(SomeTypeRef arg) {
  arg->>someFunc(); // безопасно
V>}

V>void reportEmpty() {}

V>SomeTypePtr ptr = GetOptionalPtr();
V>func(ptr); // автоконверсия в NotNull, выбросит исключение, если NULL

V>if(ptr)
V>   func(ptr); // безопасно, ноль дополнительных проверок

V>ptr.dispatch(func, reportEmpty); // функциональный стиль.
V>[/ccode]

V>В Хаскеле возможен только IoC вариант, т.е. рантайм-диспетчеризация как в последней строчке:
V>[haskell]
V>data Optional t = Default | Specific t;

V>func :: Optional SomeType -> Void
V>func (Specific ptr) = someFunc ptr
V>func Default        = reportEmpty
V>[/haskell]

V>Да, до некоторого предела вложенности компилятор при оптимизации производит распространение констант, поэтому часто рантайм-диспетчеризация заменяется на прямо вызов, но в современных С++ эта оптимизация куда глубже/качественней, так шта мой С++ вариант будет соптимизирован лучше.

S>>Внезапно значительная часть ссылок оказывается non-nullable.

V>Какое открытие! ))

S>>А nullable reference нужны не чаще чем, скажем, Nullable<int>. Как-то же работает C# с int? безо всяких IoC и коллбеков. Удивительно, да?

V>Не работает, [url=https://learn.microsoft.com/en-us/dotnet/api/system.nullable-1.value?view=net-7.0]RTFM[/url]! ))
V>Выбрасывает исключения.

V>>>Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin. 
S>>(facepalm). Тут прекрасно всё - и "даже" Котлин, как вершина развития языкостроения, и применение IoC для борьбы с nil, и диспетчеризация... 
S>>Жаль, что всё современное программирование прошло мимо вас.

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

V>ОК, дай мне пример языка, которым ты владеешь хотя бы на самом начальном уровне, где есть строгая первоклассная поддержка non-nullable ссылок.
V>Скорее всего, у тебя в копилке ни одного такого языка нет.
V>Но очередное громкое заявление про "современное программирование" было! ))

V>В общем, такие языки есть, но их нет в мейнстриме.
V>Более того, многие из них достаточно старые.

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

V>Посмотри, например, языки, со встроенной поддержкой зависимых типов, как там обыгрывают подобные сценарии.

V>>>А фраза целиком лишь характеризует уже старого и недостаточно умного человека.
S>>Забавно, что вы тут усердно опровергаете утверждение "программисты прошлого были умнее".

V>Хоар и был умнее.
V>Человеку почти 90 лет, тут не стоит манипулировать/спекулировать.

S>>Видите, и Хоар вам недостаточно умён.

V>1. Один из распространённых приёмов демагогии.
V>2. Я ответил на эти спекуляции заране, зная тебя. Увы, не помогло. ))

V>Я уверен, что стоит тебе только начать копать проблематику первоклассной поддержки non-null ссылок в языках, и тебе станет мучительно стыдно за вопросы про диспетчеризацию или про обязательную поддержку исключений как альтернативу явной или неявной (как в Хаскель) диспетчеризации. 
V>(Хотя, поддержка исключений - это тоже своего рода неявная диспетчеризация, бгг...)

S>>Да, я помню, для вас и Билл Гейтс недостаточно успешен :)))

V>Цитату или балабол.
V>Там ты мне это приписывал, помнится, примерно как здесь приписываешь, что я считаю Хоара глупым.

V>Я считаю высказывания постаревшего Хоара глупыми, и они, действительно, глупы, чего только стоит сравнение с косой чертой.
V>А когда он принимал те или иные решения, он был в расцвете своих способностей, принимал эти решения куда как осмысленней.

V>>>В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
S>>Эта фраза показывает, что вы не понимаете сути "проблемы нулевых ссылок".

V>Да нет, эта фраза показывает, что ты не понимаешь зависимых типов.
V>Проблема же не только в null, ссылка вообще может ссылаться на мусор в памяти.
V>Т.е. простая проверка на не null не решает вопрос окончательно.

V>В языках с зависимыми типами индекс не может вылезти за пределы массива никак, прямо на уровне типов.
V>Точно так же, как ненулевая ссылка не может принять нулевое значение.
V>Ссылка вообще не может принять невалидное значение.

V>>>И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная?
S>>Надо полагать, оттого, что проблема - [i]не в точности[/i] идентичная.
V>>>Это ровно один и тот же класс ошибок, вызванных одной и той же причиной - невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime.
S>>Это какой-то очень широкий класс ошибок.

V>Уфф...
V>Адрес - это индекс ячейки памяти.
V>Проблема невалидного адреса в точности равна проблеме невалидного индекса.

V>И ведет к асболютно идентичным ошибкам - к неверной реентерпретации памяти.
V>Я тебе в C# запросто создам управляемую ссылку на мусор в памяти (произвольный адрес, не обязательно null).

V>И никакое #nullable enable не спасёт.
V>Да и оно сейчас пока живёт как ворнинги.
V>И запросто обходится через !, без рантайм-проверок.

V>Это ты вот это всё имел ввиду под "современным программированием"? ))

V>В общем, в языках с зависимыми типами нет принципиальной разницы на допустимые ограничения, контроллируемые системой типов, будь это [0, 1, 2] или [0, 1..] 
V>Там работает один и тот же механизм.

V>Синтаксически в разных языках это может выглядеть по-разному, но по-сути происходящего - идентично.
V>Опять же, зависит от наличия или нет исключений в языке!

V>Например, в языках с зависимыми типами без исключений может применяться flow control,
V>т.е., некий uint[0..MAX_UINT] может быть приведёт к ограниченному типу uint[0..10] через простой if:
V>[ccode]
V>uint array[10] = ...;
V>uint x = readX();
V>func(array[x]); // ошибка компиляции

V>if(x < 10)
V>   func(array[x]); // OK, тип переменной x модифицируется контекстом предыдущих вычислений
V>[/ccode]

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

V>Про произвольную программу речи не идёт, речь идёт об одном аспекте - о программировании в ограничениях на уровне системы типов.
V>Эти ограничения не дают неверно интерпретировать память.

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

V>Далее.
V>Способ выражения ограничений в языке в свою очередь накладывают ограничения на дизайн программы.

V>Например, во многих языках с зависимыми типами ты не можешь прочитать массив данных из файла и передать его куда-то дальше, примерно так (псевдокод):
V>[cs]
V>let array<?>(int) = readFromFile();
V>process(array);
V>[/cs]

V>Ты можешь действовать только через IoC:
V>[cs]
V>readFromFile(process<N: uint>: array<N>(int) -> Void) {
V>    let loop<N:uint> array<N>(int) ar = {
V>      ...
V>      if(eof) 
V>        process(ar);  // конец работы, вызов поданного продолжения
V>      else
V>        loop(insert(ar, data))  // хвостовая рекурсия, вызов лямбды loop с новым типом ar (с новым размером)
V>    }

V>    loop array<0>(int);  // начало цикла
V>}
V>[/cs]

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

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

V>Давай не будем о нормальности.
V>Теория зависимых типов была разработана не с 0-ля в 70-е, а первые работы на эту тему были еще в 1925-м, задолго до первых компьютеров.
V>Не надо считать всех идиотами. ))

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

S>>В частности, "проблема" нулевой ссылки легко статически разрешима на более-менее любой современной платформе.

V>Если ты про C#, то анекдот хороший.

S>>Даже настольные языки, собранные на коленке энтузиастами, прекрасно обходятся без нулевых ссылок.

V>Фортран тоже обходился без нулевых ссылок.
V>Да и вообще любые языки, где явное оперирование динамическими структурами невозможно. ))

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

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

S>>Кстати, вопросы индексов в массивах давно закрыты: https://www.cs.cmu.edu/~fp/papers/pldi98dml.pdf. Так то про "невозможность в компайл-тайм" - это лично ваши заблуждения. Развивайтесь, читайте.

V>- Ты куда, в баню?
V>- Да нет, в баню!
V>:facepalm:

V>И зачем ты даёшь столь неинформативную статью со столь бедными примерами, если есть полно отличных статей, описывающих проблематику и способы их решения, а так же ограничения на конструкты, которые допускают "распространение" типизированности по данным? 
V>В т.ч. на русском.
V>Это тебе первая ссылка на англоязычном гугле подкинула и ты не читая кинул, чтобы поднадуть щеки? :)))

V>И статью ты ниасилил, иначе бы не сверкал невежеством тут:
V>[q]
S>>IoC и функциональные языки соотносятся примерно никак.

V>>>В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
S>>Эта фраза показывает, что вы не понимаете сути "проблемы нулевых ссылок". 
V>[/q]

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

V>Ты обратил по ссылке внимание на сам принцип написания программ?
V>Это другой принцип проектирования.

V>Показан один из беднейших инструментов реализации ЗТ - хвостовая рекурсия, каждый раз вызывается локальная ламбда с новым типом аргументов.
V>И вот как раз конечный результат вычислений можено будет подать куда-нибудь далее в вычислениях поданному как аргумент функциональному объекту, потому-то и IoC, что список неизвестного размера нельзя вернуть из ф-ии. ))
V>Можно только вызывать другую ф-ию в типизированном контексте.

V>>>(в языках, которые претендуют на хоть какую-то эффективность)
S>>Эта фраза тоже выдаёт непонимание сути проблемы. Как раз [i]неэффективное[/i] решение проблемы и состоит в переносе проверок в ран-тайм.

V>Проверки в рантайм всё-равно есть, вопрос в том - сколько их.
V>Ведь достаточно проверить один раз (или достоверно получить валидное значение по new) и далее распространять значение уже с признаком валидности.

V>Насчёт "непонимания сути" - опять улыбнуло.
V>Это ты в своём C# не понимаешь сути, потому что нет алиасов типов, невозможно отсутствие конструктора структуры без параметров.
V>Поэтому ср-вами языка проблему не решить - нужен встроенный костыль.

V>А я тебе выше показал примеры на C++, которую столь узкую постановку вопроса решают на раз-два.
V>Причём, с нулевым оверхедом, в сравнении с обычными указателями.
V>И без переделки исходников, т.к. Optional<T*> и NotNull<T> - это умные указатели, с переопределёнными operator-> и operator*, т.е. их можно использовать там, где ожидался обычный указатель, только теперь можно распространять non-nullable указатели без лишних проверок.

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

V>Увы, увы.
V>Программы, написанные в этом стиле, как по ссылке, построены таким образом, что в функции всегда передаются другие функции-"продолжения".
V>Т.е. вся работа основной программы - это бесконечный вызов ф-ий из ф-ий.
V>Но стек ведь не бесконечен? Отсюда монады и ленивость.
V>То бишь, "энергичный" вызов ф-ий заменяется динамически выстроенным графом продолжений, где вычисления передаются динамически же вычисленным в процессе работы программы веткам графа через явные if или неявную дистептчеризацию, на манер Хаскеля.
V>То бишь, никакого call не происходит, вычислительная модель языка в ленивой манере протягивает монаду процесса/потока по этому графу вычислений.

V>То бишь, вычисления выглядят в рантайме так:
V>func1 -> result1 -> func2 -> result2 -> func3 -> ...

V>И до чудес быстродействия там как до звёзд.

V>>>И до изобретения исключений, без техники IoC, т.е. без функциональных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код компилятором (...) и аварийно завершить программу, если проверка на индекс или nil была неудачной.
S>>И опять вы складываете в одну кучу рантайм и компайл-тайм проверки. Это вы мухлюете или вправду не видите разницы?

V>Это ты не понял прочитанного. ))
V>Медитируй до просветления, плиз.

V>>>Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков.
S>>Вот как раз тут прямо таки [i]нового[/i] появилось не очень много.
V>>>Без изобретения нового.
S>>Воот! В основном то, что мы наблюдаем - приезд в мейнстрим идей и концепций из 1960х. Так что "теории языков" вычёркиваем.

V>В 70-х только начали [i]классифицировать[/i] типизированные лямбда-исчисления.
V>Классификация была нужна для понимания (1) необходимого и достаточного набора конструктов языка для соответствия выранным критериям и (2) для понимания необходимых техник программирования в данном классе ограничений, см [url=https://ru.wikipedia.org/wiki/%D0%9B%D1%8F%D0%BC%D0%B1%D0%B4%D0%B0-%D0%BA%D1%83%D0%B1]лямбда куб[/url] (наглядное представление классификации).

V>В 60-х еще вопрос так не стоял, т.к. выразительные ср-ва компилятора диктовались сугубо объемом оперативной памяти, которой располагал компилятор в процессе своей работы.

V>Ну и, в 60-х годах, таки, разработкой языков занимались математики, поэтому языки те были полны в рамках выбранных концепций, в отличие от наколенных языков от энтузиастов сегодня.

V>Сегодняшние столь же "академические" языки в мейнстриме - это Golang, Dart, Хаскель.
V>И то, мейнстрим весьма условный. ))

V>F# (OCaml), Scala, Kotlin - уже нет.

V>C# - совсем нет.
V>В рамках выбранной концепции он далеко не полон, не обладает всеми необходимыми выразительными св-вами.
V>Собсно, поэтому развитие языка запросто идёт дальше при сохранении бинарного формата сборок еще аж со времён 2-го дотнета.
V>Блин, указатели на ф-ии только-только ввели.
V>Через stackalloc стало можно размещать не только примитивные целочисленные типы вот только недавно.
V>И т.д. и т.п.

V>>>Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду:
V>>>http://www.rsdn.org/forum/philosophy/4247637.1
S>>Ну, так и зачем самому себе противоречить?

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

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

V>Как тебе задача - выделить из данной цепочки символов всевозможные подцепочки максимальной длины, встречающиеся более одного раза.
V>Оцени сложность в терминах O.
V>Умножь на многие мегабайты размеров современных программ.
V>Это всего лишь одна из подзадач в процессе оптимизации - склейка самоповторов после стирания типов на одной из стадий оптимизации.
V>Сначала над типами работает бета-редукция и генерирование уникального кода из генерик-представления.
V>(А чуть ли не весь код на Хаскель - это сплошные генерики в терминах C#)

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail