xoxlobandera | Reading

На выходныхъ сидѣлъ съ богомерзкимъ ИИ. За нѣсколько часовъ реализовалъ интерпретаторъ небольшого игрушечнаго языка программированiя.

Получилъ отвѣты на вопросы типа: какая библиотека быстрѣе для парсинга, имѣетъ ли смыслъ использовать Parametric HOAS или простой HOAS въ разныхъ варiантахъ.

Но совершенно ничего не узналъ и не понялъ собственно про технику реализацiи языковъ программированiя. Читать кодъ - "некогда, пилить надо". Да и недостаточно это - читать кодъ. Кодъ надо писать самому.

Собственно не получилъ никакихъ знанiй, скажемъ, про HOAS, какъ и почему онъ работаетъ, можно ли его упростить или ускорить, гдѣ слабыя мѣста. На бенчмаркахъ увидѣлъ, что HOAS въ 100 разъ быстрѣе наивной ADT-реализацiи (data Term = Var a | Lambda Term Term | App Term Term) на одной бенчмаркѣ и на 50% медленнѣе на другой. Почему? Можно ли какъ-то поправить дѣло? Пока неизвѣстно. Бенчмарки пришлось править вручную - богомерзкiй ИИ накосячилъ такъ, что за всю ночь такъ и не заканчивался процессъ.

Пока что два практическихъ вывода:

- При пользованiи ИИ полезно всегда видѣть, сколько стоилъ каждый запросъ. Видѣть, сколько еще осталось за мѣсяцъ. Это сильно помогаетъ принять рѣшенiе не использовать ИИ для той или иной конкретной задачи.

- Использовать ИИ только какъ справочникъ, замѣну гуглу. Какiя опцiи въ такой-то программѣ, почему не устанавливается, что означаетъ такая-то ошибка. Все остальное думать и писать самому.

chaource

Вынесено изъ комментарiя здѣсь: https://yigal-s.dreamwidth.org/3245160.html

есть ли сейчас какой-то авторитетный источник (источники) по объектно-ориентированному дизайну и анализу?

Я давно для себя поставилъ похожiй вопросъ, но съ болѣе формально строгой точки зрѣнiя. Отвѣта у меня пока нѣтъ, есть частично какiе-то наметки.

Я не спецiалистъ именно по ООП, потому что не пришлось много въ этой парадигмѣ работать на практикѣ, а "выучить теорiю" тамъ нельзя - нѣтъ какой-либо четко сформулированной, математизированной теорiи.

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

Поэтому для меня ООП и ООД выглядятъ какъ попытки что-то сляпать на колѣнкѣ, не понимая или даже не желая понять что-либо четко и сформулировать какiя-то формальныя свойства.

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

Извѣстны попытки что-то на эту тему сдѣлать формально. Есть разныя статьи и книги такого рода. Напримѣръ, "принципъ подстановки Лисковъ" (Liskov substitution principle) сформулированъ въ математизированномъ видѣ въ статьяхъ Liskov et al. (Однако я когда-то посмотрѣлъ на это внимательно и увидѣлъ существенныя дыры, ставящiя подъ сомнѣнiе этотъ "принципъ".) Также есть книги Schlaer-Mellor на разныя такiя темы, но тамъ я не разбирался самъ, "лично не читалъ". (То есть, можно сказать, что читалъ, но не лично.)
( Read more... )

Примѣръ вопроса, гдѣ взглядъ черезъ теорiю типовъ прояснилъ ситуацiю - https://chaource.dreamwidth.org/234402.html

Примѣръ вопроса, въ которомъ я пока не смогъ разобраться - https://chaource.dreamwidth.org/235872.html

Я исхожу изъ того, что программисты уже понимаютъ на какомъ-то простомъ уровнѣ, что такое типы и какiе они бываютъ. Но интуитивное пониманiе адекватно (т.е. достаточно для правильныхъ умозаключенiй) только для простыхъ типовъ. Типы, требующiеся для ООП ("интерфейсы", "subtyping", "overriding", "dynamic dispatch") далеко не просты и не сразу понятны. Изъ-за этого разсужденiя о типахъ, дѣлаемыя ООП-программистами интуитивно, часто получаются невѣрными. Поэтому надѣжда въ томъ, что ООП-типы можно будетъ легче понять, если удастся выразить ихъ черезъ болѣе обычные типы (products, co-products, functions, generics). Въ частности, мы должны какъ-то выразить subtyping и dynamic dispatch черезъ обычные типы. Съ subtyрing я вродѣ бы разобрался, но съ dynamic dispatch пока нѣтъ.

chaource

We are working in System F where direct recursion is not supported.

All recursive types must be Church-encoded. Can we implement merge-sort on lists?

I tried this and the first problem I ran into is that I need to implement a merge function for two sorted lists. In Haskell, this would be:

mergeSorted :: [Int] → [Int] → [Int]
mergeSorted [] r = r
mergeSorted l [] = l
mergeSorted (a : b) (c : d)
  | a < c = a : mergeSorted b (c : d)
  | otherwise = c : mergeSorted (a : b) d

This code is recursive and is not allowed in System F.
We need to begin by defining a Church-encoded list type, e.g., like this:

let ListNat = ∀(r : Type) → r → (Natural → r → r) → r

let nilNat : ListNat
    = λ(r : Type) → λ(nil : r) → λ(cons : Natural → r → r) → nil

let consNat : Natural → ListNat → ListNat
    = λ(head : Natural) → λ(tail : ListNat) →
      λ(r : Type) → λ(nil : r) → λ(cons : Natural → r → r) →
        cons head (tail r nil cons)

let example : ListNat = consNat 1 (consNat 2 (consNat 3 nilNat)) -- This is [1, 2, 3].

In the Church encoding, a list is a higher-order function with a type parameter. System F does not support directly recursive code. We can implement a recursive algorithm on lists if we are able to express it via applications of that function to some arguments.

For example, concatenation on lists looks like this:
( Read more... )

S	M	T	W	T	F	S
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

just

Reading

Богомерзкiй ИИ - 13. Что дѣлать

Существуетъ ли наука объектно-орiентированнаго программированiя?

God-awful AI, part 12. Write some difficult code for me

Profile

August 2025

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags