Это копия, сохраненная 22 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
К тому же, Лисп упаковывает структуры, а C распаковывает и выравнивает, в итоге структуры в Лиспе весят меньше, как мы узнали в предыдущем треде.
Холиварный, но не совсем бездоказательный, тред продолжается здесь.
Предыдущий ждёт сборки мусора тут: >>1477327 (OP)
Перекачу сюда, очень интересно узнать:
У меня вопрос не по теме ОП-поста, но связанный с его стилистикой и настроением.
Много ли альт-райтов, NRx или правых акселерационистов в IT-сфере? Молдбага и Ника Ланда кто-нибудь читает?
>потому что на современном железе работает всё
Лолнет.
>ПОЧЕМУ О:=Н:=И ТАК ЛЮБЯТ МУТАБЕЛЬНОСТЬ?
Потому что синтаксис арифметики построен на школьной математике х= а + б - с*20 тип так всем понятно.
Такой синтаксис в свою очередь вынуждает переиспользовать имена переменных.
Другая причина, это быстрые алгоритмы и структуры данных.
Например хештаблица\словарь. Массив, и так далее.
А вообще, ОП, тебе лечиться нужно.
Как иммутабельность упростит мне реализацию алгоритма поиска пути (Дейкстры, например)? Предлагайте функциональное решение.
299 Кб, 1452x1936>это где ты вычитал такое? что x86 подгоняли под язык си?
Первый в линейке x86
Intel 8086 (iAPX 86)
https://en.wikipedia.org/wiki/Intel_8086
>Marketed as source compatible, the 8086 was designed to allow assembly language for the 8008, 8080, or 8085 to be automatically converted into equivalent (suboptimal) 8086 source code, with little or no hand-editing
> Instructions directly supporting nested ALGOL-family languages such as Pascal and PL/M were also added
>8086 also introduced some new instructions (not present in the 8080 and 8085) to better support stack-based high-level programming languages such as Pascal and PL/M;
>While perfectly sensible for the assembly programmer, this makes register allocation for compilers more complicated compared to more orthogonal 16-bit and 32-bit processors of the time such as the PDP-11, VAX, 68000, 32016 etc
Под DEC Vax писали на Си.
Второй в линейке x86
80286
https://en.wikipedia.org/wiki/Intel_80286
>The 80286 was designed for multi-user systems with multitasking applications, including communications (such as automated PBXs) and real-time process control
https://en.wikipedia.org/wiki/ORCA/Modula-2
Он был разработан под популярный в то время Modula-2
Третий iAPX432 и первых 32х битный цп
https://en.wikipedia.org/wiki/Intel_iAPX_432
>The iAPX 432 was referred to as a "micromainframe", designed to be programmed entirely in high-level languages
> the iAPX 432 programming model is a stack machine with no visible general-purpose registers. It supports object-oriented programming[5], garbage collection and multitasking as well as more conventional memory management directly in hardware and microcode. Direct support for various data structures is also intended to allow modern operating systems to be implemented using far less program code than for ordinary processors.
>They applied fashionable computer science concepts from universities, particularly capability machines, object-oriented programming, high-level CISC machines, Ada, and densely encoded instructions
Четвёртый - 80386
Имеющий поддержку Си, и якобы "превосходящий" в "эффективности" iAPX_432, на самом деле Си стал очень модным к этому времени. Кроме того я подозреваю, что, тот факт, что ADA использовался(и используется) в военном секторе, разработке просто не дали хода в массы.
Реальную годноту заменили 80386 дерьмом стыдливо переписав историю везде где могли.
>The example code uses the EBP (base pointer) register to establish a call frame, an area on the stack that contains all of the parameters and local variables for the execution of the subroutine.
>A flat memory model is assumed, specifically, that the DS and ES segments address the same region of memory.
http://bitsavers.trailing-edge.com/components/intel/80386/231499-001_80386_System_Software_Writers_Guide_1987.pdf
>Offset-only pointers match the C language's uniform view of the address space.
RISC
https://ethw.org/Milestones:First_RISC_(Reduced_Instruction-Set_Computing)_Microprocessor_1980-1982
Professors David Patterson and Carlo Sequin of the University of California at Berkeley observed that compilers for high-level computer languages, such as C, rarely utilized the added instructions. They thought that overall performance could be improved by optimizing the combination of processor function and memory on a single chip. Better overall performance at a much lower cost might be achieved by simplifying the processor, thereby allowing more chip area to be devoted to memory. Thus the goal was defined as a RISC, or reduced instruction set computer.
299 Кб, 1452x1936>это где ты вычитал такое? что x86 подгоняли под язык си?
Первый в линейке x86
Intel 8086 (iAPX 86)
https://en.wikipedia.org/wiki/Intel_8086
>Marketed as source compatible, the 8086 was designed to allow assembly language for the 8008, 8080, or 8085 to be automatically converted into equivalent (suboptimal) 8086 source code, with little or no hand-editing
> Instructions directly supporting nested ALGOL-family languages such as Pascal and PL/M were also added
>8086 also introduced some new instructions (not present in the 8080 and 8085) to better support stack-based high-level programming languages such as Pascal and PL/M;
>While perfectly sensible for the assembly programmer, this makes register allocation for compilers more complicated compared to more orthogonal 16-bit and 32-bit processors of the time such as the PDP-11, VAX, 68000, 32016 etc
Под DEC Vax писали на Си.
Второй в линейке x86
80286
https://en.wikipedia.org/wiki/Intel_80286
>The 80286 was designed for multi-user systems with multitasking applications, including communications (such as automated PBXs) and real-time process control
https://en.wikipedia.org/wiki/ORCA/Modula-2
Он был разработан под популярный в то время Modula-2
Третий iAPX432 и первых 32х битный цп
https://en.wikipedia.org/wiki/Intel_iAPX_432
>The iAPX 432 was referred to as a "micromainframe", designed to be programmed entirely in high-level languages
> the iAPX 432 programming model is a stack machine with no visible general-purpose registers. It supports object-oriented programming[5], garbage collection and multitasking as well as more conventional memory management directly in hardware and microcode. Direct support for various data structures is also intended to allow modern operating systems to be implemented using far less program code than for ordinary processors.
>They applied fashionable computer science concepts from universities, particularly capability machines, object-oriented programming, high-level CISC machines, Ada, and densely encoded instructions
Четвёртый - 80386
Имеющий поддержку Си, и якобы "превосходящий" в "эффективности" iAPX_432, на самом деле Си стал очень модным к этому времени. Кроме того я подозреваю, что, тот факт, что ADA использовался(и используется) в военном секторе, разработке просто не дали хода в массы.
Реальную годноту заменили 80386 дерьмом стыдливо переписав историю везде где могли.
>The example code uses the EBP (base pointer) register to establish a call frame, an area on the stack that contains all of the parameters and local variables for the execution of the subroutine.
>A flat memory model is assumed, specifically, that the DS and ES segments address the same region of memory.
http://bitsavers.trailing-edge.com/components/intel/80386/231499-001_80386_System_Software_Writers_Guide_1987.pdf
>Offset-only pointers match the C language's uniform view of the address space.
RISC
https://ethw.org/Milestones:First_RISC_(Reduced_Instruction-Set_Computing)_Microprocessor_1980-1982
Professors David Patterson and Carlo Sequin of the University of California at Berkeley observed that compilers for high-level computer languages, such as C, rarely utilized the added instructions. They thought that overall performance could be improved by optimizing the combination of processor function and memory on a single chip. Better overall performance at a much lower cost might be achieved by simplifying the processor, thereby allowing more chip area to be devoted to memory. Thus the goal was defined as a RISC, or reduced instruction set computer.
>тьюринговые машины
сферическое говно в вакууме
все современные компы - реализации машины/архитектуры фон неймана, сам термин software подразумевает мутабельность
> что современные машины построены как тьюринговые машины состояний, но это очень слабый аргумент
Слабый, если ты мозгом слабый. Машины без состояний являются более примитивными и всегда появляются раньше. Копье появилось раньше лука, а логические схемы - раньше процессора.
Когда нам предлагают иммутабельный язык, нас пытают опустить на более низкий технологический уровень, засунуть в эдакий досбокс.
Нуб проглатывает эту ловшку - ведь действительно простейшие программы, да еще с бэкграундом в виде школьной математики, написать проще. А дальше работает синдром утенка. Нуба заманивают в ФП, обещая ему золотые горы, а потом говорят: ну знаешь, мутабельность на самом деле нужна, мы ради нее микропроцессор придумали, поэтому вот тебе переусложненный воркфлоу по написанию мутабельных программ в иммутабельной среде.
А ты сам себе не противоречишь? Вычисления в процессоре произодятся в регистрах общего назначения => мутабельность переменных => иммуабельность тебует более высокого уровня абстакции от архитектуры
Мимино
> К тому же, Лисп упаковывает структуры, а C распаковывает и выравнивает, в итоге структуры в Лиспе весят меньше, как мы узнали в предыдущем треде.
И ты это плюсом к производительности считаешь, что ли?
Вот потому мы и любим то, в чём разбираемся (а вы - нет).
Где там хоть слово про производительность? Вот поэтому мы разбираемся в том, о чём прочитали (а вы — нет).
Дегенераты отвечают перефорсом. The Thread.
Почему же автораспараллеливающийся код на лиспах-хаскелях работает медленнее, чем однопоточный код на няшной?
Но в математике действительно нет мутабельности. Где она там? Переменные? Они для каждого случая генерируют новое значение, а не изменяют начальное. Формулы? Там чистая иммутабельность — суёшь на вход свои данные, получаешь сгенерированные формулой данные на выходе. Никакого стейта, чистейшая функциональщина.
Два чая.
Ты больной.
Причём тут машины? Машина не шлюха, чтоб ее ублажать.
Важен код сам по себе, его читаемость, предсказуемость и понятность для человека. Бизнес-правила по своей природе декларативны и языком отношений описываются более ясно, чем языком тумба-юмба: «взять копье; убить мамонта: съесть мясо». Прогрессом как раз является язык, позволяющий выражать высокоуровневые понятия обобщенным языком. Естественно компиляторы таких языков получаются намного сложнее и даже после всех оптимизаций код зачастую получается медленнее кода на говняшной. Тем не менее, это направление которое очевидно нужно развивать, а не продолжать ковырять говно ложкой на процедурной параше ещё и гордится этим.
Кроме того, что они очевидным образом занимают меньше места? Упакованные структуры хороши при передаче данных побитовым методом, а практически любые данные передаются таким методом.
К чему вся эта портянка текста??
Кого волнует подо что подгоняли 8086??
И блятть истории других музейных процов - тоже унесите нахуй отсюда
Под лиспом обычно подразумевают общелисп.
Схемки и др.рекеты слишком тонкие, поэтому подходят только для лабок, ну а кложа - не тру.
> они очевидным образом занимают меньше места
> 2019
> очень много памяти, но медленной
> отсутствие выравнивания - плюс.
Ну ёб же вашу мать, граждане - мы же не двадцатый век обсуждаем, когда было наоборот.
> Упакованные структуры хороши при передаче данных побитовым методом
Это вообще что-то непонятное. Что за передача побитовым методом, куда?
И нет, я не говорю, что функциональщина плохо (интерфейсы без побочных эффектов банально легче читать), но вы ж реальных плюсов за лесом не видите, набрасываясь на то, в чём не разбираетесь.
Иммутабельность и ФП это конечно заебись, но тут за них адвокатируют в основном безмозглые жопаскрипт-говноеды на волне хайпа, которые с этими концепциями знакомы только понаслышке ведь на функциональном языке они никогда в жизни не писали и думают, что ФП - это когда объектов нет и функции передаются в функции. Поэтому если здесь кто-то начинает брызгая слюной озвучивать, что мутабельность это корень всех бед, что ООП говно и прочие не требующие мыслительной активности религиозные догмы, можно не разбираясь записывать его в жс-мартышки и ссать на ебало.
>Вычисления в процессоре произодятся в регистрах общего назначения => мутабельность переменных => иммуабельность тебует более высокого уровня абстакции от архитектуры
Запуск досбокса тоже требует более выского уровня абстракции.
Ты путаешь уровни абстракции и уровень технологий.
Поддержу изо всех сил.
> при передаче данных побитовым методом, а практически любые данные передаются таким методом.
Ох йобт
Как многого я не знаю
А чо сразу жсмартышки жсмартышки? В жс пару ситуаций где иммутабильность нужна/полезна. Первое объекты типа Date (в самом жс он мутабельный) чтобы себе яица не отстрелить. Второе говно типа редакса. Там иммутабельность тоже по практическим соображениям нужна - если не поменять объект стейта то реакт внутрь не заглянет и нахуй пошлет не перересует интерфейс.
жсмартышка
Смотря в какой. В том же Racket изкоробки без дополнительных изъёбов хуй тебе, а не set-car! и set-cdr!.
>кложа - не тру.
Почему? Раньше у кложахейтеров был аргумент про стектрейсы, которые в крайнем релизе починили. Что теперь не так?
82 Кб, 946x1184ФП = лютые тормоза
Адепты этого говна всегда отвечают что современные компиляторы умеют оптимизировать это всё так чтобы не лагало. Но это пиздёж, на практике мы видим что это не так.
В ракете из коробки есть мутабельные пары и списки.
Кроме того всё что через дефайн декларированно может быть мутировпнно функцией (set! var val)
Автор очередного чатика на электроне порвался, спешите видеть.
Предлагаю ещё ввести сверхмутабельность - когда окружение настолько нестабильно, что данные меняются сами собой.
>Но это пиздёж, на практике мы видим что это не так.
Где видим, в твоём манямирке? Пруфы или пиздобол.
>К чему вся эта портянка текста??
>Кого волнует подо что подгоняли 8086??
Анонов, которые задавали ответы. Я принёс вопросы. Продолжение обсуждения из предыдущего треда.
Твоя в чем проблема, обиженный?
А ты ваще батина сперма, а не человек.
я думаю, что те реализации лиспа, что содержат в себе оптимизирующие компиляторы в машкод целевой платформы, пишут бутстрапом скорей всего
в dr racket так то jit компилер есть, помимо интерактивного режима.. алгоритм сборки мусора современный.. машкод генерится под x86-64, под arm..
те он может выполняться как си-шарп или явка..
но, в отличие от этих мейнстрим языков, у тебя будет и интерактивный режим, repl, который позволит вести быструю разработку и отладку, делать интроспекцию и рефлексию прямо на лету, на выполняемом экземпляре программы..
>но, в отличие от этих мейнстрим языков, у тебя
Будет неконсистентная дерьмо стандартная библиотека, и говнодокументация.
Где fold можно применять только к спискам блядь.
Где лютый микс из разных стилей кода, одна хуйня на классах, другая на структурах.
Про тайпед ракет лучше не начинать говорить, говно полное, SBCL на голову лучше.
А на вопросы по типу - как использовать ХМЛ либу(потому что документация настолько дерьмо), "комьюнити" будет предлагать написать свой собственный DSL для парсинга ХМЛ.
>в dr racket так то jit компилер есть
Джит компилятор в IDE? Ты че несешь?
Алсо, ракет переводят на ChezScheme, так что это теперь костыльная обертка поверх чужой виртуальной машины.
> В ракете из коробки есть мутабельные пары и списки.
Ну да, с (require rnrs/mutable-pairs-6) и с mcons/set-mcar/set-mcdr вместо cons/set-car/set-cdr, что я и назвал изъёбами.
>А на вопросы по типу - как использовать ХМЛ либу
Справедливости ради, в ракете можно использовать либу Олега для xml, которая, несмотря на хуёвую документацию один хуй исходники придётся читать, может быть использована в элегантном функциональном стиле.
> Про тайпед ракет лучше не начинать говорить, говно полное, SBCL на голову лучше.
Полностью согласен, CL вообще так-то говнище сраное примерно на уровне современного мейнстрима, но racket ещё хуже.
>Ну да, с (require rnrs/mutable-pairs-6)
Наркоман сраный https://docs.racket-lang.org/reference/mpairs.html
Никаких require ненужно.
Еще раз, из коробки.
>Справедливости ради, в ракете можно использовать либу Олега
Да, знаю про нее, вроде норм. (я уже запарсер руками с регекспом и такой-то матерью)
Я к тому, что обещанные "батарейки" в ракете из говна сделаны...
> примерно на уровне современного мейнстрима
Есть какие-то соображение на счёт того на чем можно вообще работать с комфортном.
Julia может? Но там какая-то проприетарщина имеет место быть...
Раст?
Я пытался уйти на лисп с сисярпа, и мне постоянно не хватает каки-х то банальных удобств.
Всегда чего-то не будет. Сисярп заталкивается мелкомягкими, половина мира на винде сидит, если не больше. Да и сахар в других языках обычно другой и совсем не так на зубах хрустит, как ты привык, и у либ имена какие-то странные, а функций не хватает.
Так что сам решай, чего ты хочешь. Например, раст очень приятный, сам знаю, но пока ты не переучишься с классов — где ты делаешь объект по типу другого объекта — на трейты — где ты выделяешь одинаковое поведение у объектов и реализуешь его для всех, — ты будешь плеваться и топать ногами. А пока не научишься писать макросы, будешь тихо ненавидеть такие места, где отличаются одна-две детали, но реализовывать их надо по-разному и копипастой. А пока будешь учить макросы, будешь громко ненавидеть тех, кто сделал макросы такими сложными.
>Например, раст очень приятный
Ок, я к нему начал приглядываться сразу как разрабы Racket объявили что хотят ИЗМЕНИТЬ ОСНОВНОЙ СИНТАКСИС в Racket 2, чтобы были на питон похоже, а то студенты жалуются...
Лисп нравился давно, но со времён моей юности, он не на шаг не продвинулся.
Например в тот же стандарт схемы влепили зачем-то сраный тров катч с выворачиванием потока выполнения, это когда в языке первоклассный континюации то...
И чар у них отличается от того что стриг хранит - это совсем шиза.
>И чар у них отличается от того что стриг хранит
Ты про Раст? ASCII чар — это просто u8, и его можно записывать буквами: let a = b'A';
Тип "char" имеет длину в четыре байта из-за юникода, а строка из N знаков имеет длину меньше чем 4xN из-за того, что в расте строки в utf-8 кодировке, так что строка только из ASCII знаков будет иметь длину 1хN. Всё логично, в общем-то, чтобы потом разрабы не ебались с переводом строк из ASCII-only в Unicode при переводе, но непривычно сперва, это да.
Да чет нелогично нехрена.
В чем логика использовать для чара другой тип данных?
Если строка это не список\массив чаров, то в чем сакральный смысл чара как явления?
Ну, в данном случае строка это список, навигация по которому сплошной ад.
Вот чет врасте то-же херню ссобачили.
>в общем-то, чтобы потом разрабы не ебались с переводом строк из ASCII-only в Unicode при переводе
Я даже не знаю их имен (не понимаю что за перевод такой и что за проблема)
Строка это последовательность символов, точка.
А массив байтов в котором символы как-то закодированы, это массив байтов, это не строка.
Короче наплодили сущностей на ровном месте.
Я видел в расте мутируемую строку или что-то такое, ну и как этот чудо раст определит что я хочу 5тый символ в строке поменять?
Будет идти по списку и считать?
А потом будет подвигать все оставшиеся байтики в зависимсоти от того меньше новый символ байтиков занимает или больше чем старый?
Это реальная шиза.
>А потом будет подвигать все оставшиеся байтики в зависимсоти от того меньше новый символ байтиков занимает или больше чем старый?
Ты utf-8 хоть раз видел? Нихуя там двигать не надо, просто вставить байты между нужными тебе знаками. Но найти нужный знак по индексу не выйдет, если ты не знаешь с какого байта он начинается. И такая фигня крайне редко требуется, а когда требуется, просто превращает строку в итератор по чарам или в массив чаров и с ним работаешь. А если у тебя в строке только ASCII, то и превращать нихуя не надо и по индексу можно вставлять.
>не понимаю что за перевод такой
Обычный перевод с английского на любой другой язык. Как ты переведёшь "qwe" на русский, если у тебя в чаре вмещается всего 256 знаков? Будешь подключать новую либу и менять везде строки на строки из этой либы? А как ты теперь эту строку изменять будешь, если у тебя вся логика завязана на то, что чар занимает один байт?
>В чем логика использовать для чара другой тип данных?
Чар занимает четыре байта места. Строка в utf-8 виде крайне редко занимает 4xN байтов. Просто экономия места. А если у тебя вся работа завязана на вставку чаров и строк в середину другой строки, то никто не мешает тебе сделать свою строку, которая будет массивом чаров. Но я уже говорил, что такая херня требуется крайне редко, а массив чаров занимает намного больше места, чем те же чары в строке; память сегодня дешёвая, конечно, но не бесплатная же, а раст вроде как системным программированием занимается.
> В чем логика использовать для чара другой тип данных?
Шел 2019-ый год
Еще не все понимали что такое юникод
Кому интересны истории музейных процов, которые ни одной осью уже не поддерживаются?
Да я сам в шоке.
>>40725
>Нихуя там двигать не надо, просто вставить байты между нужными тебе знаками.
Utf-8 имеет переменную длину символа.
Как я просто блядь вставлю 2х байтный символ на место однобайтного или наоборот?
>>40725
>>А потом будет подвигать все оставшиеся байтики в зависимсоти от того меньше новый символ байтиков занимает или больше чем старый?
>Ты utf-8 хоть раз видел? Нихуя там двигать не надо, просто вставить байты между нужными тебе знаками. Но найти нужный знак по индексу не выйдет, если ты не знаешь с какого байта он начинается. И такая фигня крайне редко требуется, а когда требуется, просто превращает строку в итератор по чарам или в массив чаров и с ним работаешь. А если у тебя в строке только ASCII, то и превращать нихуя не надо и по индексу можно вставлять.
>Обычный перевод с английского на любой другой язык.
Что ты несешь.
>Как ты переведёшь "qwe" на русский,
Специальной либой, онлайн сервисом?
>если у тебя в чаре вмещается всего 256 знаков?
Ты ебанутый? Сам же писал что чар 4х байтный. Это юникод называется.
>Будешь подключать новую либу и менять везде строки на строки из этой либы?
Я не понимаю проблемы, ты ерунду порешь.
>А как ты теперь эту строку изменять будешь, если у тебя вся логика завязана на то, что чар занимает один байт?
Каким же нужно быть дегенаротом, чтобы тип "текстовый символ" делать однобайтным?
Зачем мне себе такие проблемы создавать
>Чар занимает четыре байта места.
И?
>Строка в utf-8 виде крайне редко занимает 4xN байтов.
Допустим.
>Просто экономия места.
Какова длинна обычной текстовой строки в средней программе по твоему?
И что на счёт ресурсов на парсинг этого дерьма?
>А если у тебя вся работа завязана на вставку чаров и строк в середину другой строки, то никто не мешает тебе сделать свою строку
>никто не мешает тебе сделать свою строку
Опять шизофреники.
В ракете предлагали свой ЯП писать для парсинга ХМЛ, в Расте предлагают свой стринг изобретать.
Убогие.
>а массив чаров занимает намного больше места
Сколько в абсолютных значениях?
>память сегодня дешёвая, конечно, но не бесплатная же, а раст вроде как системным программированием занимается.
Если ввели тип строки, то он должен работать как строка.
А если массив байт, то нефиг его строкой обзывать.
Да я сам в шоке.
>>40725
>Нихуя там двигать не надо, просто вставить байты между нужными тебе знаками.
Utf-8 имеет переменную длину символа.
Как я просто блядь вставлю 2х байтный символ на место однобайтного или наоборот?
>>40725
>>А потом будет подвигать все оставшиеся байтики в зависимсоти от того меньше новый символ байтиков занимает или больше чем старый?
>Ты utf-8 хоть раз видел? Нихуя там двигать не надо, просто вставить байты между нужными тебе знаками. Но найти нужный знак по индексу не выйдет, если ты не знаешь с какого байта он начинается. И такая фигня крайне редко требуется, а когда требуется, просто превращает строку в итератор по чарам или в массив чаров и с ним работаешь. А если у тебя в строке только ASCII, то и превращать нихуя не надо и по индексу можно вставлять.
>Обычный перевод с английского на любой другой язык.
Что ты несешь.
>Как ты переведёшь "qwe" на русский,
Специальной либой, онлайн сервисом?
>если у тебя в чаре вмещается всего 256 знаков?
Ты ебанутый? Сам же писал что чар 4х байтный. Это юникод называется.
>Будешь подключать новую либу и менять везде строки на строки из этой либы?
Я не понимаю проблемы, ты ерунду порешь.
>А как ты теперь эту строку изменять будешь, если у тебя вся логика завязана на то, что чар занимает один байт?
Каким же нужно быть дегенаротом, чтобы тип "текстовый символ" делать однобайтным?
Зачем мне себе такие проблемы создавать
>Чар занимает четыре байта места.
И?
>Строка в utf-8 виде крайне редко занимает 4xN байтов.
Допустим.
>Просто экономия места.
Какова длинна обычной текстовой строки в средней программе по твоему?
И что на счёт ресурсов на парсинг этого дерьма?
>А если у тебя вся работа завязана на вставку чаров и строк в середину другой строки, то никто не мешает тебе сделать свою строку
>никто не мешает тебе сделать свою строку
Опять шизофреники.
В ракете предлагали свой ЯП писать для парсинга ХМЛ, в Расте предлагают свой стринг изобретать.
Убогие.
>а массив чаров занимает намного больше места
Сколько в абсолютных значениях?
>память сегодня дешёвая, конечно, но не бесплатная же, а раст вроде как системным программированием занимается.
Если ввели тип строки, то он должен работать как строка.
А если массив байт, то нефиг его строкой обзывать.
>Если ввели тип строки, то он должен работать как строка.
>А если массив байт, то нефиг его строкой обзывать.
Ты сам себе противоречишь. Ты как раз хочешь массив байтов или чаров, а у нас в расте строки.
>И что на счёт ресурсов на парсинг этого дерьма?
Всяким парсерам охуенно, они сразу читают String как utf-8, никакого парсинга из массива в строку.
>Ты сам себе противоречишь. Ты как раз хочешь массив байтов или чаров, а у нас в расте строки.
Я хочу строки, у вас массив байтов в ебнутой обертке.
Или строки в РАСТений списками сделаны? Охуеть тогда экономия памяти конечно.
>Всяким парсерам охуенно, они сразу читают String как utf-8, никакого парсинга из массива в строку
Это так не работает. Или я отстал от жизни.
Ну хоть пример покажи парсинга хмл читаемого из стрима.
> Ну хоть пример покажи парсинга хмл читаемого из стрима.
Чувак, я не понимаю что ты вцепился в ебаный XML
Но похоже, что ты про SAX и DOM понятия не имеешь
>Чувак, я не понимаю что ты вцепился в ебаный XML
Для примера.
Подойдёт любой текстовый протокол. Например HTTP.
Хочу посмотреть как ваши строки не строки в расте упрощают парсинг.
Да ты не маневрируй!
> Ну хоть пример покажи парсинга хмл читаемого из стрима.
Тыык: про XML SAX парсеры ты не знаешь
> строки не строки
Что ты называешь строкой? Что ты называешь char-ом?
Ты до сих пор не понял, почему символ может быть не одним байтом?
>Я хочу строки, у вас массив байтов в ебнутой обертке.
Нет типа строки который бы хорошо подошел для всех случаев.
Кому-то нужно экономить место (utf8), кому-то обрабатывать посимвольно максимально удобным образом (utf32).
Я тебя конкретный код прошу показать. Ты серьёзно считаешь что я хмл парсером не умею пользоваться? А себя на основании блядь знания о SAX возомнил неебатся каким экспертом?
>Да ты не маневрируй!
Маневрируешь тут только ты.
Хватит нести хуйню.
Тебя попросили показать конкретный код демонстрирующий преимущество стрингов не использующих чар в кач базового типа в парсинге.
Тип строки нужен для обработки посимвольно максимально блядь удобным образом.
Когда нужно экономить каждый байтик ты просто задаёшь байтики константы через сахарок, или без.
utf8 это вообще ошибка, костыли совместимости, и используют её для передачи и хранения. И нехрен пихать её туда, где она не нужна, например туда где нужна обработка текста, как то строки в яп.
Ну ладно у раста есть оправдание(слабое) что тип мы как сишка ну чтобы с дерьмолегаси совместимость.
А у ракета какое? Бомбит в общем.
Люди которые это делают оторваны от реальности.
Когда речь идёт о строках байтики никому не нужны.
Блжад
Малчек, ты в курсе сколько строковых типов придумано за историю программирования?
О каком конкретно строковом типе ты говоришь?
В каком языке, какой технологии?
>В любой момент можешь написать Vec<char>, никаких проблем нет, элементарное действие.
>"РРЯ! Вы раки, нахуя вы стринги делаете utf-8! Вы что, долбаёбы, не сможете написать логику кодировки сами? Это же просто, это же не ебаный вектор с чарами, в котором хуй пойми что одного размера! Это же просто куча побитовых операций, определение длины символа, а не что-то сложное, как унифицированный insert() для вектора! Это же можно в любой момент написать за день, никаких проблем, это же не что-то сложное, как Vec<char>, где надо написать АЖ ДЖВА СЛОВА! Хрть-фу на вас, опущенцы!"
Ты совсем туту?
Речь шла о расте. Ты выше заявил что строки в нём построены не на чарах а на массиве байт в utf8 кодировке, и что это заебись как удобно для парсинга.
Я предлагаю тебе продемонстрировать это удобство.
Любая работа с текстовыми файлами в utf-8. Если тебе надо поменять в файле все "Hello!" на "Hello, world!", то ты просто читаешь файл сразу как строку или несколько строк, находишь в этой строке совпадение с "Hello!" последовательностью байтов, вычисляешь стартовый байт для "!" знака и вставляешь туда ", world" последовательность байтов. Всё. А в твоём случае надо как минимум один раз превратить utf-8 строку в Vec<char>, потом там искать последовательность из чаров, потом обратно в utf-8 перегонять получившийся текст.
>Кому-то нужно экономить место (utf8), кому-то обрабатывать посимвольно максимально удобным образом (utf32).
>
насколько я понимаю, проблема раста в том что он НЕ оставляет выбора, внутреннее представление строки в нем всегда utf8
это странно для языка, претендующего на универсальность
второе, опять же очень странное решение выбирать utf8, когда язык претендует на то чтобы быть самым быстрым на планете, лол
utf8 явно для этого не подходит, так как кодирует символы переменной длиной, что очевидным образом замедляет работу с такими строками, по сравнению с представлениями юникода в которых фиксированная длина символа
42 Кб, 500x498Чет не понял почему ты порвался. Чтобы использовать тип данных "строка" с представлением в utf8 нужно реализовать сложную кодировку.
Или ты о том что делать пользователю библиотеки когда он хочет текст сохранить? Ну не знаю, что-то вроде stringToBaytiky("idi nahuy", tip.utf8) ?
У вас там мозги совсем растом покрылись?
>нужно реализовать сложную кодировку.
И раст реализует её в std::string::String. А нам предлагают пойти на хуй с этой реализацией и пользоваться массивом чаров, потому что, видите ли, "не строка-с, батенька".
127 Кб, 960x9331. Пример кода на расте демонстрирующий преимущество растрвских строк для подобного редактирования файла будет или нет? Из твоего описания совершенно непонятно в чем преимущество конкретной реализации строк в расте. Какой мне толк от них если я вручную должен всерано нужные байтики находить?
2. Ты на полном серьёзе предлагаешь изменять ТЕКСТОВЫЙ ФАЙЛ ПРЯМО НА ДИСКЕ ПО КУСОЧКАМ ?
Ты понимаешь вообще что современные ФС имеют блоки от 4к и cow во все поля?
45 Кб, 750x867Записывать строки как "пошёл на хуй", а не [byte; N]? Кроме скорости работы ещё и удобство в использовании.
С utf8 не работают, в нем хранят и передают.
Даже в сишке блядь wchar.
А тебя, как и других раст трансвеститов, лечить нужно.
1. Чтобы так их ЗАПИСЫВАТЬ ненужно делать базовый тип стринг на основе блядь ютф8.
ToUtf8("sukabluat") уже мозгов не хватает сделать?
Растенианцы не осилили текстовые константы?
2. А если у меня данные не в ютф8? Я их хоть сконвертировать в этом чудорасте смогу?
Если тебе надо сделать utf-8 строку из utf-16, то в std либе есть from_utf16(). А любая utf-32 строка — это как раз массив растовых char'ов. А если у тебя какая-то другая кодировка, или тебе работать надо не с utf-8 или utf-32 строками, то иди на хуй искать или писать либу для этой кодировки, потому что подавляющему большинству людей такая кодировка не нужна.
ты заебал тупить
в utf8 хранить удобно, тк компактное представление
а "работать" с ним нихуя не удобно и медленно, сука
типичная задача: заменить все вхождения одного символа на другой, и тут, опа - заменяемый символ в 1 байт, а заменитель - в 2 байта
и получается что приходится для такого случая полностью перетряхивать строку, делать реаллок, и полную перезапись
в то время в двубайтовом представлении ты просто проходишь по строке заменяя вхождения
вторая типичная задача: заменить n-ный символ
в двубайтовой кодировке (или любой другой с фиксированной длиной символа) ты просто делаешь смещение, что очень быстро и заменяешь
а в utf8 тебе придется пробегать по всей строке чтобы вычислить позицию n-го символа, а потом уже заменять
я вообще не умею кодить в расте, но если у них там внутреннее представление юникода в utf8, то это пиздец
Если у тебя строка в utf-16, то возьми либу для utf-16 строк, заебал. Мне пока что хватало utf-8 формата, utf-16 обычно китайцы используют.
А если тебе надо работать с массивом чаров некоторого размера, то делаешь себе нужные типы:
use Str32 as Vec<char>;
use Usc2 as Vec<u16>;
Ещё раз, если ты тупой: работа со строками — это работа со строками: всякие слепливания одной строки из нескольких, поиск слов в строке и удаление или добавление слов или строк, разделение одной строки на несколько, удаление пробелов оттуда, где они не нужны. Для всего этого как бы похуй, как представлена строка, потому что ты просто с определённой последовательностью байтов работаешь. Но строки занимают места меньше, чем массив чаров.
А если тебе надо заменить один элемент в массиве на другой, то ты и работай с массивом, блядь. Что непонятного?
>заменить n-ный символ
>в двубайтовой кодировке (или любой другой с фиксированной длиной символа)
Ну, если у тебя строка уже готова в таком виде, то хули и нет. А если тебе на вход поступает utf-8 строка, в которой надо заменить один символ, а потом вернуть эту же строку в utf-8 формате, то один раз найти N-й символ и заменить его в utf-8 виде выйдет намного быстрее, чем ту же utf-8 строку переделать в массив чаров, потом в нём заменить N-й элемент, а потом обратно запихивать этот массив в utf-8 кодировку.
И если ты захочешь ещё раз пиздануть про скорость замены одного элемента массива на другой, то сперва принеси приложение, которое таким постоянно занимается в контексте строк. Потому что хуй ты такое найдёшь, 90% приложений (не для китайского языка, разумеется) хватает иммутабельных строк, которые можно склеить, а другим 9% хватает изменяемых строк в виде сжатого в utf-8 массива байтов. Строки делают вовсе не для работы с чарами в них.
>Для всего этого как бы похуй, как представлена строка
нет, не похуй
операции со строками медленней в utf8
Ты аутист сраный.
Еще раз, с UTF8 НЕ РАБОТАЮТ.
Это кодировка для хранения и передачи, НЕ ДЛЯ ОБРАБОТКИ.
Пиздец, как можно быть таким упоротым.
Тебе уже на пальцах объяснили, что приведенная тобой же задача по замене - сплошной ад в utf8.
Кроме процессорного времени это еще и память жрет, внезаптно.
Тебе нужно каждый раз всю строку переписывать при любом изменении.
35 Кб, 550x412>А если тебе на вход поступает utf-8 строка, в которой надо заменить один символ, а потом вернуть эту же строку в utf-8 формате, то один раз найти N-й символ и заменить его в utf-8 виде выйдет намного быстрее, чем ту же utf-8 строку переделать в массив чаров, потом в нём заменить N-й элемент, а потом обратно запихивать этот массив в utf-8 кодировку.
Одним единственном редким случаем не встречающимся на практике оправдывать дизайн такой важной вещи как стринги?
>И если ты захочешь ещё раз пиздануть
Вот это интеллектуал прорвался так сказать.
>то сперва принеси приложение, которое таким постоянно занимается в контексте строк
Редактор например комментария в котором ты свой высер на двач простишь?
И как на счёт операции которую почти везде можно встреть, взятие подстроки?
Или trim ?
Ты понимаешь вообще что дизайнеры раста обосрались, а ты себя в этом засохшем дерьме вымазал.
Ну поведай мне, борщегений программирования, каким образом в этой utf8 строке реализуется удаление пробелов С КОНЦА строки?
>Одним единственном редким случаем не встречающимся на практике оправдывать дизайн такой важной вещи как стринги?
Стринги чаще хранятся, чем меняются. И тут utf-8 хорош. Так что дизайн оправдан.
> каким образом в этой utf8 строке реализуется удаление пробелов С КОНЦА строки?
> в строке удаление
Йобанный ты Рип-Ван-Винкль!
За такую хуйню уже лет 30 как пиздят ногами!
В любом языке!
>Стринги чаще хранятся, чем меняются. И тут utf-8 хорош.
блядь, ты троллишь тупостью, да?
окей, пусть не меняются, и что?
чтобы в utf8 получить доступ к n-му символу, надо, блядь, пробежаться по всей строке с начала
а это значит что целый, блядь, класс строковых алгоритмов начинает работать дохуя медленно
в то время как в представлениях юникода с фиксированным размером символа, нужно взять лишь смещение
никто не говорит о том, чтобы в языке (либо в самом языке, либо в его стандартной библиотеке) не было средств работы с utf8, но внутреннее представление юникода лучше выбирать с фиксированным размером символа
Так у нас есть char тип, хуле. Но читаешь-то ты из utf-8 типа чаще всего, потому что всё хранится в этом виде. Вот если тебе нужно работать с чарами, так и делаешь из строки Vec<char>, а потом творишь всё что надо с этим массивом, пока отправлять куда-то не придётся, в чём проблема?
Скажи мне, в чём различие между операциями над массивом из чаров, из u16 или из u8 и твоей строкой с фиксированным размером символов? Если ты читаешь usc-2 строку, так и читай её прямо в Vec<u16>. А если utf-32, то в Vec<char>. Вот прямо на пальцах мне объясни, каких действий с вектором тебе не хватает, чтобы работать с ним как со строкой из фиксированной длины символов?
>чтобы в utf8 получить доступ к n-му символу, надо, блядь, пробежаться по всей строке с начала
Чтобы превратить utf-8 строку в массив char типа, тоже надо по всей utf-8 строке пробежаться.
>внутреннее представление юникода лучше выбирать с фиксированным размером символа
Так чаровый тип же. Или о каком представлении ты говоришь? Ты учитывай, что раст — компилирующийся во всякие .exe системный язык со строгой типизацией, так что там сколько байтов на тип выделишь, столько и будет. Нет никакого внутреннего представления, ты работаешь с тем типом, который САМ выберешь.
Единственное, что можно назвать "внутренним представлением" — это то, как хранятся константные строки (хардкорно записанные в .exe файл, то есть данные, которые СОВЕРШЕННО, НИКАК, ВОТ ВООБЩЕ НИКАК НЕЛЬЗЯ ИЗМЕНИТЬ, ТОЛЬКО ПРОЧИТАТЬ), которые как раз хранятся в utf-8 виде. Но тут и спорить не о чём, если ты не китаец, потому что данные, которые можно только хранить и читать, нет смысла хранить в виде отличном от максимально сжатого.
>Но читаешь-то ты из utf-8 типа чаще всего
Читают или из константы или из байтовой стримы.
Иди лечись уже, горе погромист.
>Чтобы превратить utf-8 строку в массив char типа, тоже надо по всей utf-8 строке пробежаться.
Fuck off retard.
>в чём различие между операциями над массивом из чаров, из u16 или из u8 и твоей строкой с фиксированным размером символов?
ты продолжаешь троллить?
в utf8 чтобы перейти к n-му символу, нужно пройти от начала стоки до этого символа, блядь
в utf16 ты просто делаешь смещение
окей, utf8 - самая пиздатая кодировка на земле, а раст-программисты самые охуенные и скоро все вокруг будет работать на расте
аминь
Мы как на разных языках говорим. Тут все из какой-то динамически типизированной параши набежали? Что, с крестов и сишки вообще никого нет?
Массив из чаров растовых — это массив из четырёхбайтовых значений. Массив из u16 — массив из двубайтовых значений, массив из u8 — массив из однобайтовых значений, сраная аския. Всё фиксированного типа.
К тому же, в utf-16 не фиксированная длина символа, только в ucs-2, иди учи матчасть.
а фп-зумеры соснули
Ты ебанутый - ты об этом знаешь?
Посмотри на ОП-пост - где ты видишь чего-то про раст?
Ну ты вообще ебанутый, а точнее безграмотный шопыздец:
- строки блядь пытаешь эффективно мутировать - это невозможно
- пиздишь про XML, про который все позабыли - и не знаешь про SAX
Хуево тобой быть!
435 Кб, 825x464Во-первых, как связаны программирование и (((правый))) акселлерационизм?
Во-вторых, Кирилл Нестеров, залогинтесь.
>Такой синтаксис в свою очередь вынуждает переиспользовать имена переменных.
Мутабельность и скопинг никак не связаны. В вполне функциональном лиспе лексический скоупинг, имена можно переиспользовать хоть до посинения.
>Например хештаблица\словарь. Массив, и так далее.
Словари встроенны во многие ФП по дефолту. Массивы с O(1) доступом к элементу реально нужны не так часто, как это может показаться.
>А потом удивляемся тому что новый софт тормозит как ебаная сука.
Новый софт пишут исключительно на хачкеле и кложе, это всем давно известно.
>Массивы с O(1) доступом к элементу реально нужны не так часто, как это может показаться.
Если язык настолько кастрирован, что из него убрали циклы, то да, не нужны.
155 Кб, 1502x898Хвостовая рекурсия стэк спейс жрет. Твердо и четко.
https://stackoverflow.com/questions/310974/what-is-tail-call-optimization
Ну да. Там где цикл хранит одну переменную, твоя рекурсия хранит по одной переменной на каждый вызов рекурсивной функции.
Зачем тебе котлетки, когда есть Карл Маркс.
Поясни, я не понял. Компилятор/интерпретатор вызывает функцию и кладет результат на стек, следующий вызов берет результат со стека и кладет новый, и так повторяется n раз. Что я упускаю?
А если серьезно, то полная иммутабельность не нужна за пределами академических языков типа Haskell. Это не отменяет того, что list comprehension, pattern matching, мапы, фолды, фильтры, да даже монады -- это очень крутые штуки и это хорошо, что их добавляют в популярные языки. К тому же, ФП это одна из двух полноценных парадигм программирования, из используемых сейчас, в отличие от современного ООП, которое является костылем к императивной парадигме.
Собственно Гвидо все написал на твоем пике.
Хвосторекурсивный код там, где нужен цикл - это пиздец. Это вручную пробрасываемый стейт в виде параметров функции, отказ от структурного программирования, трудности со стектрейсами, и, главное, не понятно, зачем. К ссылочной прозрачности циклы внутри функции все равно отношения не имеют.
Комбинаторы - иногда сокращают код, когда он сводится к таким комбинаторам. Но это опять же вопрос котлеток и коммунизма: я-то могу использовать комбинаторы в своем императивном коде, а могу не использовать.
Готу указатели хранить надо на каждый рекурсивный вызов. В императивке сам решаешь, какой стейт сохранить, а какой можно дропнуть. Возьмём тот же фибоначчи. В императивке ты тупо хранишь одну переменную под предыдущее значение. Посчитал следующее, дропнул или перезаписал предыдущее. В хвостовой рекурсии надо всё сохранять. Или я неправ?
>Готу указатели хранить надо на каждый рекурсивный вызов.
Так там один и тот же готу на каждый вызов, функция то не меняется. Меняется только результат функции, который дропается на стек и который подбирает следующий вызов. Чи не?
Ну Молдбаг айтишник. И первые статьи про NRx в американских медиа были написаны в таком духе, мол, это идеология гиков и кодеров.
Ну хуй знает.
На мой взгляд, акселлерационизм это какая-то залупа. Технологии подвержены энтропии, как и все на белом свете, и если их специально не развивать, то они начнут деградировать. Технологическая сингулярность может быть и наступила бы, если бы люди имели идеальную память, к сожалению, это не так. В любой момент можно все забыть и наступит пролапс коллапс цивилизации.
https://www.youtube.com/watch?v=ZSRHeXYDLko
Блядь, ну ты мудак ебучий, в раст только аутистов берут? Вот тебе строка: "café façade". Посплитай её по символу é . Обосрамс? Обосрамс.
>современного ООП, которое является костылем к императивной парадигме.
вангую что тебе никогда не приходилось городить кучу макросов вкладывающих одни структуры в другие и состоящих из указателей на функции в чисто сишном проэкте, тк требовалась сэмулировать иерархию интерфейсов, которая в с++ делается обычными классами с наследованием.. или городить те же vtable ручками, тогда как в крестах опять же динамический полиморфизм из коробки.. и прочее..
ну да, еще вирт писал о том что в структурных языках нет необходимости использовать хвостовую рекурсию, тк она легко переписывается на циклы (и в последнем случае более наглядна)
с другой стороны, когда рекурсивный алгоритм более сложен (к примеру, типичная задача - фракталы), то использование рекурсивного вызова функций дает более наглядную реализацию алгоритма, чем итеративная реализация на циклах
>- строки блядь пытаешь эффективно мутировать - это невозможно
поясните за этот вскрик (я просто с другой стороны окопа: структурное программирование, ооп, etc)
дело в том что "Массив из чаров растовых", это, блядь не строка
реализация класса (библиотеки или чего там в твоем языке) строки предполагает реализацию множества специфичных операций для строки (к примеру, те же сравнения, поиск подстроки, возврат подстроки, конкатенацию, числовые преобразования и еще кучу другого, к примеру возможность передачи на обработку в библиотеку регулярных выражений)
а "массив из чаров" остается массивом, с набором операций, типичных для массива, а не для строки
Если ты мутируешь строки - ты дебил
Если ты ищешь способ их эффективно мутировать - вдвойне дебил
Доступно?
эээ, нет
одни оскорбления
положим, нужна капитализация строки
в чем проблема сделать ее по месту?
не всегда выгодно с точки зрения производительности порождать новую строку
> не всегда выгодно с точки зрения производительности порождать новую строку
Всегда блять выгодно дебил ты ебаный!
Исключая гигабайтные размеры
Но если у тебя гигабайтные строки - ты пиздец дебил
Современные процы не любят байтоебства по месту
Лезть с рекурсией в разговор о хвостовой рекурсии не очень умно
Всё, кроме парсинга чарового массива в число, реализуется методами вектора изичайше. Парсинг чарового массива в число можно просто полностью спиздить из стд либы, изменив в той функции пару строк.
о, узнаю мантры расто-фанатиков (с придурками из мозиллы во главе, второй раз убивающими свой браузер)
все, абсолютно все можно переписать!
сделать это легко и просто!
перепишем весь мир, перепишем его заново, юзеры подождут
знаешь, реализовать эффективный поиск подстроки (для наиболее общих случаем при помощи КМП или боером-муром или более спец алгоритмы), с оптимизациями, промышленного качества - это совсем не простая задача, на самом то деле, с которой не всякий и хороший программист справится.. в любом случае это потребует затрат времени..
но, ожидается, что класс строки в библиотеке общего назначения, которую ты юзаешь, уже будет иметь эффективную реализацию поиска подстроки и тебе не нужно будет тратить на реализацию его время
Что? О чём ты? Я говорю, что все функции, которые ты хочешь применять к строкам в виде чаровых массивов, — можно написать за время от нескольких минут до часа. Какое переписывание? Ты совсем поехал?
>Всегда блять выгодно дебил ты ебаный!
как, блядь, выгодно?
вот язык си
вот есть строка, лежит в памяти, мы берем и по месту делаем капитализацию ее
а иначе нам надо попросить памяти, скопировать в нее строку, и уже там делать капитализацию
как это выгодно?
напиши мне поиск подстроки КМП алгоритмом с оптимизациями промышленного качества реализацию
ЗА ЧАС
на своем vec<char>
блядина
Хватит кормить жирного растошизика. Он очевидно троллит тупостью.
Нашёл статью про строки в расте.
https://lise-henry.github.io/articles/optimising_strings.html
Описывается задача замены нек символов на другие.
И это я должен сказать полная ШИЗа.
Оказывается нет никакого uf8 поиска, ты должен вручную итерировать по стрингам получая из них чары.
> вот есть строка, лежит в памяти, мы берем и по месту делаем капитализацию ее
А теперь иди читай, как работают современные процы и подсистемы памяти
Побайтное дрочево перестало работать в 80-ых годах
Хуйню несешь
Ну, предположим.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=35565a40c59aa073d0f3eec8fed4a153
Чего тебе ещё сделать?
Копированием всей строки у тебя больше шансов сбросить кеш.
Не говоря уже о выделении памяти.
>Побайтное дрочево
Так мы тут о яп для побайтового дрочева говорим. Проснись.
мда
Так я не говорю, что ООП говно или нинужно, просто по факту это реально костыль, а не отдельная парадигма. Костыль очень удобный и нужный, но костыль.
Если вкратце, то ИП и ФП это фундаментально разные подходы просто потому, что это две разные модели вычисления, которые изначально вообще не имели ничего общего, пока не был доказан тезис Тьюринга -- Чёрча. ООП не представляет новую модель вычисления, а строится поверх уже существующей ИП парадигмы.
с теоретической точки зрения ооп - это один из вариантов как можно представить в языке расширяемую систему пользовательских типов, как задавать отношения между ними
те в cs ооп относится к моделям типизации, а не к модели вычислений, если просто писать
вот
С теоретической точки зрения про ООП вообще говорить невозможно, потому что ООП не было формализовано ни в каком виде.
Заебал мелкобуквенный
>не было формализовано ни в каком виде
Which part of "The technique of using dynamic polymorphism to call functions without the source code of the caller depending upon the source code of the callee." you don't understand?
у ооп есть теоретическое обоснование, тот же "принцип подстановки лисков" и все такое..
другое дело что положения ооп взяты как частный случай из теоретических работ по типизации, по заданию отношений между типами и все такое, так чтож в cs предпочитают работать над более общими системами типов
"принцип подстановки лисков" дает определение подтипа в ооп, теоретическое обоснование динамической диспетчеризации (дин полиморфизма) дал джузеппе кастанья в своих работах..
>А ООП до сих пор является просто набором практик без четкой формализации.
Ты описал любое программирование
Ты дебил? Я тебе скинул формализацию ООП, его основной определяющий принцип, который позволил людям вздохнуть спокойно и перестать писать на сишке.
Ты не можешь в чисто функциональном языке писать императивный код, по-крайней мере без костылей в виде монад.
Ты не можешь в чисто императивном языке (типа Си) писать функциональный код, по-крайней мере сделать это будет очень тяжело.
Но в том ООП, которое используют большинство популярных языков, ты можешь писать императивный код без особых проблем. Просто объявляй все методы public static и ты даунгрейднулся до Си.
Речь то не о том, что тру-ООП не представляет из себя что-то самодостаточное. Речь о том, что ООП в том виде, в котором оно реализовано в плюсах, шарпе, жабе и т.д,, -- это не самодостаточная парадигма, а костыль над императивным программированием. Да, есть тру-ООП языки типа Смолтока и Симулы, ну и много людей сейчас используют Смолток и Симулу?
>Ты не можешь в чисто функциональном языке писать императивный код
>по-крайней мере без костылей в виде монад.
Так можешь или не можешь? Определись. И заодно дай-ка определение "чисто функционального" языка, а так же расскажи, в какой момент появляется грязь.
>Просто объявляй все методы public static и ты даунгрейднулся до Си.
А Объектно-Ориентированное Программирование-то где будет в этом случае? Пальцем покажи.
>Так можешь или не можешь? Определись.
Ну как бы это будет не совсем императивный код, do notation -- это синтаксический сахар для того, чтобы пробрасывать "стейт" через функции, стейта как такового там нет.
>И заодно дай-ка определение "чисто функционального" языка
Вот с википедии:
>In computer science, purely functional programming usually designates a programming paradigm—a style of building the structure and elements of computer programs—that treats all computation as the evaluation of mathematical functions. Purely functional programming may also be defined by forbidding changing-state and mutable data.
Purely functional programming consists in ensuring that functions, inside the functional paradigm, will only depend on their arguments, regardless of any global or local state.
>в какой момент появляется грязь
Когда пропадает referential transparency.
>А Объектно-Ориентированное Программирование-то где будет в этом случае?
В том и смысл, что его не будет.
Да. Это формальные системы, на которых строятся языки.
У ООП нет никакой формальной системы.
Это просто хуйня в воздухе "мы так придумали"
Ну то есть твои охуительные аргументы заключаются в:
1) На С нельзя писать ФП-код, то есть можно, но лучше не надо
2) В ФП-языках нельзя писать императивный код, то есть можно, но лучше не надо.
3) А вот в ООП языках можно выкинуть объекты и писать как на сишке, но лучше не надо, а значит ООП не самостоятельная парадигма
Че?
>a style of building the structure and elements of computer programs—that treats all computation as the evaluation of mathematical functions
>The technique of using dynamic polymorphism to call functions without the source code of the caller depending upon the source code of the callee.
В чем разница между этими двумя определениями, и почему одно является "формализацией", а второе внезапно нет?
>Да. Это формальные системы, на которых строятся языки.
Это просто источник вдохновения для автора языка. К программированию отношения не имеет.
Ладно, я сдаюсь, ООП самостоятельная парадигма. Доволен?
Я говорю не про тру-ООП, а как это выглядит на практике. Скатиться до голой императивщины в жабе намного проще, чем в Си до функциональщины или в Хачкеле до императивщины.
>В чем разница между этими двумя определениями, и почему одно является "формализацией", а второе внезапно нет?
Я вообще не топил за формализацию, ты меня путаешь с другим аноном. Стремление формализовать все на свете -- это психическое расстройство.
>Ну как бы это будет не совсем императивный код
Тогда если написать на хаскеле интерпретатор брейнфака, и захардкодил там программу в строку, то код не будет императивным.
Это все чушь. Код, эмулирующий императивность, является императивным. При его анализе возникают все прелести императивности, а именно становится необходимым трейсить состояние. Какой бы ты стек абстракций при этом не навернул.
>Когда пропадает referential transparency.
Это вообще не при чем. В ФП даже локального изменения стейта нет, который ссылочной прозрачности никак не мешает
>Скатиться до голой императивщины в жабе намного проще
Наверное потому что жаба - императивный язык?
Хуясе просто блять!
Почитай Хоара "Communicating Sequential Processes"
Или гораздо проще - Кодда по реляционной алгебре
Или Horn clauses - основы для логического программирования
Я серьезно говорю, там не так и сложно и не так много.
Это не хачкелевая тягомотина.
Но это нормально проработанные формальные системы.
ООП - не имеет никакой основы.
Какой-то калифорнийский ебанат по обкурке что-то нафантазировал что и сам не понял.
>чем в Си до функциональщины или в Хачкеле до императивщины.
...т.к. в Си это морально тяжело обходиться без состояния (ибо как минимум стандартная библиотека не стейтлес ни разу), а Хачкель тебя бьет по рукам, когда ты пытаешься что-то поменять. Хочешь состояний? Пиздуй учить теркат.
Хотя здесь валиден контраргумент, что никто не пишет на чистых функциональных языках, кроме борщехлебов, лол.
>>43012
>В ФП даже локального изменения стейта нет, который ссылочной прозрачности никак не мешает
Мешает, если у тебя функция -- единственный возможный примитив. С другой стороны, на практике таких языков нет (кроме чистой лямбды без всего), так что тут прав скорее ты.
Просто ООП настолько вжилось в ландшафт, что люди сейчас не представляют, что такое не-ООП код, и о чем вообще весь этот ООП-дискурс.
Вот так было до ООП: https://github.com/qrush/unix/blob/master/src/c/c10.c
Ты заебал теоретик
Нет никаких чистых функциональных языков в природе
Что значит "чистый"??
Без ввода и вывода?
>ООП - не имеет никакой основы.
Блять, тебе уже сказали, основа ООП - это вызов полиморфных функций без сурс-код зависимости на эти функции, либо опровергай и показывай, где такое практиковалось вне ООП, либо иди нахуй.
>Охуеть. Сделать джамп по пойнтеру, сохраненному в памяти на кусок кода - это неебаться парадигма
Именно так, простой перенос поинтера породил целую нахуй парадигму, задоминировавшую профессию, потому что это оказалось пиздец как удобно и практично. Претензия в чем?
Локальный стейт не мешает никому. Функции, меняющие внутри себя локальные переменные ссылочно прозрачные, в многопоточной среде он никак себя не проявляет, и вообще никаких головных болей не несет.
Глобальный стейт мешает всем, он него один гемор и лучше избавляться.
Но проблема ФП-языков в том, что они у них основной враг, перепидорашивающий языки до неузнаваемости (хвостовая рекурсия вместо циклов, списки с мусоросборником вместо массивов и т. д.) - это как раз локальный стейт. Потому что британским ученым мешает как раз локальный стейт. Он слишком усложняет анализ, а ученым проще пилить гранты, упростив задачу себе, а не приблизив ее к реальной жизни.
То есть если бы кто-то хотел сделать язык с сылочной прозрачностью, на котором можно было бы программировать, в нем бы были циклы. Но целевой аудитории под такой язык нет. Потому что
1. Грантоедам нужно именно отсутствие локального стейта, для доказывания унылых теорем
2. Практики и так знают, что глобальный стейт - зло, и минимизируют его использование
Тебе еще рано разговаривать со мной
В том что ты в глаза не видел первые ООП-языки
Джамп по пойнтеру - это асм инструкция
Она ничем не плоха и не хороша.
Такая же как операции сложения или обращение к памяти
Нет, шизоид, легкодоступного стейта в функциональных языках нет не из-за заговора жидов, а потому что ты хуй проведешь границу между локальным и глобальным. Если 10 из 11 функций программы могут оперировать над куском стейта(например передавая его друг другу), но глобально он технически недоступен, то это локальный стейт или какой?
>хвостовая рекурсия вместо циклов
Рекурсия в современных ФП-языках считается плохой практикой и вместо нее есть дохуя и больше способов пройтись по массиву, которые синтаксически ничем от цикла не отличаются.
>а потому что ты хуй проведешь границу между локальным и глобальным.
Эта граница называется ссылочной прозрачностью. Если функция не ссылочно прозрачна, она меняет глобальный стейт, иначе - локальный.
>Рекурсия в современных ФП-языках считается плохой практикой и вместо нее есть дохуя и больше способов пройтись по массиву, которые синтаксически ничем от цикла не отличаются.
Осталось придумать, нахуя нужно эмулировать циклы, когда есть циклы
> Рекурсия в современных ФП-языках считается плохой практикой
Чо за охуенные новости?
Что за современные ФП-языки??
Рекурсия - это буквально "повторение", как "повторение" может быть плохой практикой, ты ебанулся?
Грамматики человеческих языков рекурсивны, как без рекурсии-то блять??
Ну то есть цель одна - ссылочная прозрачность, но в одном языке ты говоришь "По умолчанию в моем языке все ссылочно прозрачно, кроме вот этих специально отведенных мест, которые выделяются и должны считаться исключением, а не правилом", а в другом "По умолчанию в моем языке нет ссылочной прозрачности, но в принципе вы можете ее сделать, если хотите, а если не хотите, то и поебать, меняйте стейт". Какой из них лучше добивается поставленной цели?
>>43088
>Что за современные ФП-языки??
Scala, Erlang/Elixir, Clojure
>как "повторение" может быть плохой практикой
Неинтуитивно, ненаглядно, плохо выражает намерение, заебешься отлавливать ошибки, если алгоритм чуть сложнее школьного вычисления чисел фибоначчи.
С рекурсией есть одна проблема, что она жрёт стек, и при большой вложенности его просто может распидорасить. Поэтому при возможности лучше использовать хвостовую рекурсию, если компилятор умеет её оптимизировать, а ещё лучше - стараться её избегать.
Рекурсия вместо простого цикла - часто говно, для этого существует много различных функций высшего порядка, типа map, foldl и пр. Это гораздо проще прочитать.
А в плане выразительности с рекурсией бывает очень даже удобно описывать какой-нибудь обход вложенных данных произвольной глубины и т.п.
>для этого существует много различных функций высшего порядка, типа map, foldl и пр.
Прикол в том, что рекурсия это зачастую и есть велосипедирование map, fold или filter.
Это копия, сохраненная 22 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.