называть динамический массив Листом - это пять Но назвать map Select'ом - это десять!!!

А стд::вектор сильно лучше?

А стд::вектор сильно лучше?

Шо то фигня, шо это фигня. Хотя в математическом смысле, пожалуй, лучше, да.

Именовать сущности сложно.

И да, соответствие нормального человеческого односвязного списка (List) в F# - это LinkedList в C# ResizeArray в F# = List в C# Array в F# (кстати он генерик) = Array в C# (Array<T>? не, не слышал)

T[] - чем не жынерик аррай? В C# LinkedList двусвязный

T[] - чем не жынерик аррай? В C# LinkedList двусвязный

Он намекал на то, что тип Array в C# не является генериком, и все эти T[] формально (с точки зрения рантайма) — тоже.

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

но вместе с упоротыми делегатами (вместо человеческой типизации функций как first-class citizen) мысль дизайн команды пошла настолько упорото далеко что теперь люди имеют delegate, Action и Func

Action и Func - частный случай делегата, можешь свои сделать какие надо Ещё EventHandler<>, Predicate<>, MethodInvoker и хренова туча других

Action и Func - частный случай делегата, можешь свои сделать какие надо Ещё EventHandler<>, Predicate<>, MethodInvoker и хренова туча других

Претензии к делегатам, по-моему, тоже вполне обоснованы. Именно это не даёт в C# писать var foo = () => 300;

это скорее воркэкраунд для языков с GC

Special Case, коих много

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

Он намекал на то, что тип Array в C# не является генериком, и все эти T[] формально (с точки зрения рантайма) — тоже.

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

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

Ну лист — генерик, а массив — не генерик. Несимметричненько получается.

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

Через такую же магию к слову делегаты работают

А уж через какую магию работает Nullable<T> — ни в сказке сказать, ни пером описать :)

Массивы - часть встроенной системы типов

Нуллабл тоже

Первое упоминание об F# 2001 год

А первое упоминание многих городов - их сожжение.

Массивы - часть встроенной системы типов

Не очень придуманной по началу, т.к. "это были суровые 90ые, мы копировали джаву как могли". Добавление генериков сделало жизнь лучше, но тяжёлое наследие сишарп 1.0 даёт о себе знать. Го2 тоже получит генерики. потому что Пайк упоротый и тоже думал что они не нужны и это кошмар

Не очень придуманной по началу, т.к. "это были суровые 90ые, мы копировали джаву как могли". Добавление генериков сделало жизнь лучше, но тяжёлое наследие сишарп 1.0 даёт о себе знать. Го2 тоже получит генерики. потому что Пайк упоротый и тоже думал что они не нужны и это кошмар

Уже есть инфа про Go2?

Уже есть инфа про Go2?

Да. Мы уже во флудилке все перетерли

В смысле, вы придумали? :)

Если коротко запасаемся попкорном и смотрим самое эпичное переобувание в историиCS

В смысле, вы придумали? :)

Лол нет

Там драфт го2 вышел вчера

Все хипстеры теперь должны придумать отмазу почему же goway обосрался

Массивы - часть встроенной системы типов

Я к тому что, не будь как гоферы. Не защищай плохой дизайн как фанатик

Не придется переобуваться

не построчно, а прям сразу тейбл

By design, таблица - это однородные строки из типизированных записей. Для объединения между таблицами join-ы, для конкатенации union

Я к тому что, не будь как гоферы. Не защищай плохой дизайн как фанатик

Я не защищаю, я констатирую тяжёлую данность

А агрегаты в виде структур и массивов на уровне языка появились даже до Си, поэтому неудивительно столь тлетворное их влияние

А агрегаты в виде структур и массивов на уровне языка появились даже до Си, поэтому неудивительно столь тлетворное их влияние

C появился в 72ом. ML с алгоритмом вывода Хиндли-Миллера а 73ем. Дженерики. В 73ем. У авторов сишарпа было почти 30 лет чтобы освоить фичи обоих языков

(я про жабу молчу-молчу-молчу)

(я про жабу молчу-молчу-молчу)

Лямбды изобрели в 32ом, а в джаве они появились лишь 80 лет спустя!!!)

Вот уж где эпичный проеб

первые лябмды реализовывались на перфокартах?

первые лябмды реализовывались на перфокартах?

На бумаге!)))

Ну, нейроинтерфейс на бумаге тоже есть, и чо?

Ну, нейроинтерфейс на бумаге тоже есть, и чо?

Архитектура фон Неймана как бы строится на машине Тьюринга, а не на лямбда исчислении для описания алгоритмов.

Это приговор декларативным языкам?

Это приговор декларативным языкам?

Нет конечно, просто это чуть менее оптимально, делать лямбды на императивной архитектуре. Но другой нет)

А было бы забавно пойди мысль в 40ых в другую сторону

ну, между декларативным "вжух" и результатом должна быть императивная реализация

ну, между декларативным "вжух" и результатом должна быть императивная реализация

Где такой физический закон есть?

в квантовых вычислениях вроде как должны это обойти

В квантовой природе вообще нет императивного состояния например.

в квантовых вычислениях вроде как должны это обойти

Да-да

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

а процесс - вполне себе императивное понятие

и только интегралы табличные :D

а процесс - вполне себе императивное понятие

Это потому что такая архитектура. Я тут недавно в дойче читал доклад на тему теорий вычислимости

Жалко запись походу проебана.

вычислительная архитектура тоже не на пустом месте строится какбэ

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

Потому что и Тьюринг и Черч описывали одно и то же.

вычислительная архитектура тоже не на пустом месте строится какбэ

Она строится на языке для формального описания алгоритмов. Таких описаний много, поэтому ждём. Может быть даже дождемся при нашей жизни.

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

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

Да это не проблема.

Нейросети декларативны, но реализация энергоэффективной не выходит ну никак

называть динамический массив Листом - это пять Но назвать map Select'ом - это десять!!!

from x in y where ... MAP ..., так что ли должно было быть? :)

from x in y where ... MAP ..., так что ли должно было быть? :)

Воу воу, палехче. Sql синтаксис выглядит по-другому Select * from TableA выбери все из таблицы А Map - это про трансформацию. Коим и является select в линк

просто map это про всё, а selеct в частности про прожекшен из коллекции, видимо чтобы облегчить переход для тех кто знает sql

Воу воу, палехче. Sql синтаксис выглядит по-другому Select * from TableA выбери все из таблицы А Map - это про трансформацию. Коим и является select в линк

Они очевидно выбирали вариант синтаксиса, понятный обывателю без научной степени

Если человек уже знает, что такое map/bind/fold, ему не составит труда запомнить Select/SelectMany/Aggregate, а вот обратное неверно - обрушить на новичка всю «правильную» теорию ФП просто чтобы найти запись в БД было бы жестко

А первое упоминание многих городов - их сожжение.

Ничего не значащую софистиау у нас обсуждают в @fsharp_flood. Так же там тоже много интересных технических разговоров

https://twitter.com/msftorleans/status/1034581783063408640?s=19

https://habr.com/company/microsoft/blog/420039/

Наконец-то! Очень жду каментов от Павлуши

Ну будут, скорее всего

По следам вчерашнего: https://github.com/ijsgaus/Paket.SDK

Запихнул я это в SDK, теперь paket скачивается и показывает help. Но надо разобраться с paket.props поскольку он связан с папкой, где лежит.

Захардкодить пути до пропсов не получится?

Запихнул я это в SDK, теперь paket скачивается и показывает help. Но надо разобраться с paket.props поскольку он связан с папкой, где лежит.

Msbuildthisfilepath

Ща

Там пути до кеша сборок. А собирается проект. Надо подумать. То ли посадить кеш сборок в user фолдер, то ли искать paket.dependencies вверх по дереву и там создавать.

А что ты хочешь в paket.props видеть?

Я просто в гите его не вижу твоем

Да я его хочу положить туда же, в сдк, и его подцеплять . <Import Project="$(NuGetPackageRoot)/paket.sdk/0.0.1-beta1/paket/Paket.Restore.targets" />

Ну и вызов поправить на dotnet paket

https://stackoverflow.com/questions/49794853/what-is-the-value-of-msbuildthisfiledirectory

Короче

В props делаешь таргет

Куда пихаешь путь до пропса

Дальше в нужном месте его реюзаешь

Точнее не таргет, а Item

Он с пакетом приходит

И вот с этим <PaketToolsPath>$(MSBuildThisFileDirectory)</PaketToolsPath> <PaketRootPath>$(MSBuildThisFileDirectory)..\</PaketRootPath> Непонятно что делать

Ну переопределить

В своем пропсе

А вот куда. Ему рутовая папка нужна. Куда кеш пакетов пихать.

Рутовая солюшна?

где paket.dependencies

Заведи <DependencyPathDir>

И переопредели

Как $(DependencyPathDir)\..