Здравствуйте, gandjustas, Вы писали:
G>>>Так это и есть та мощность языка, которую имеет смысл тут рассматривать. V>>Это выразительность. G>Ок, напиши вместо мощности выразительность. Чтонить изменится? Мы тут не корректность терминов обсуждаем.
Не термины?
G>Тогда давай формализуем понятие мощности.
Давно уже. Мощность некоторого языка — это мощность мн-ва допустимых цепочек.
Просто периодически на этом форуме, когда заходят баталии и выразительности языков кто-нить говорит, что "мн-во цепочек обычно бесконечно для обоих языков, как определить какой язык мощнее?"
Насколько велико бесконечное множество? Кантор доказал существование иерархии бесконечностей, каждая из которых «больше» предшествующей. Его теория множеств — один из краеугольных камней математики.
Здравствуйте, Vain, Вы писали:
V>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
Только в этой теме говорится о том что аналогичный запрос на С++ будет на порядки сложнее.
Так что совершенно не ясно к чему ты это сказал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
T>>Откуда негатив к Экселю ? Покажи пример. Например импортируем из экселя колонки чисел в csv формате. Покажи, как правильный файл повалит string split. S>Держите: S>
S>A,B
S>"0,77","1,22"
S>"12,44","5,23"
S>
S>Удачи со string.split.
Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.
Здравствуйте, koodeer, Вы писали:
K>Как только возникнет понимание. Хотя бы небольшое понимание. При традиционном подходе в этом случае будет создана небольшая библиотека с набором функций. В нашем случае будет создан небольшой DSL. K>По мере дальнейшего освоения специфики будет развиваться либо библиотека, либо DSL.
Здесь Wolfhound сказал что второй вариант будет на три порядке дешевле, т.е. разрабов в 10 раз меньше и в 100 раз времени меньше.
Понятно, что цифры с потолка, но хотелось бы четкие основания и более менее адекватные оценки, а не так, что взяли десять дураков, дали джаву, взяли десять толковых и посадили за ДСЛ.
T>>Специфику бизнеса люди годами осваивают и даже десятками лет. K>Скорее так: годами и десятками лет пытаются выразить специфику неудобными конструкциями языков общего назначения. Колются, плачут, но продолжают мучиться.
Здравствуйте, vdimas, Вы писали: V>Кто мешает написать своё расширение SQL, которое это может? Вы же все-равно запускаете запросы не из некой "стандартной консоли", а из своего приложения, так? Грамматика SQL проста до безобразия и в сети лежит множество готовых парсеров, которые расширить на свои потребности можно с пол-пинка.
Да в общем-то никто. Просто спроектировать это так, чтобы оно работало, не вполне тривиально. Скажем, view и SP хранятся внутри базы. А спроектированные на "внешнем языке" функции этого ESQL должны жить где-то ещё, т.к. в базе им места нету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.
Ну, предположим, операции над примитивами реляционной алгебры, выраженными в некоторых структурах данных, я напишу. Так же как транзакции, и чего? Это по-прежнему не будет предметно-зависимо, т.е. может быть даже выполнено человеком, недостаточно хорошо "плавающем" в реляционных исчислениях. Предметно-зависимы будут затем отношения и сами реляционные исчисления над ними, с помощью низлежащей инфраструктуры, и эта предметная сложность по-прежнему никуда не денется.
Матан — это не теоремы, это исследование ф-ий и их систем. В т.ч. дифференциальных и интегральных. Теория мн-в к матану не относится. "Узкие" прикладные разработки в рамках теории мн-в, типа реляционной алгебры или формальных языков и их грамматик — тем более не относятся.
WH>Во-во. Не читай про то, что не понимаешь. И тем более не комментируй.
Здравствуйте, WolfHound, Вы писали:
O>> Я просто пытаюсь понять, как компилятор позволяет определить макру в модуле, и тут же ее использовать, не скомпилировав ее и все, что в модуле было выше в динамический модуль (прошу прощения за тавтологию, тут два разных модуля — исходный файл и модуль в assembly). WH>Ты просто пытаешься понять, основываясь на модели лиспа.
Лисп не при чем. Я пытаюсь понять, основываясь на идее построения иерархии DSL.
WH>Но у меня другая модель. WH>Не менее мощная просто другая. WH>Почитай код моих генераторов парсеров. WH>Там в одной сборке описаны функции, которые занимаются переписыванием кусков АСТ. WH>И они вызывают друг друга, в том числе рекурсивно. WH>Этот подход позволяет сделать все, что ты хочешь. Но немного другим методом.
И вот в этом подходе никакой иерархии я не вижу. Хотелось бы, чтобы можно было каждый следующий крошечный DSL писать в терминах предыдущего. Делать по dll на каждый из них просто глупо и неудобно.
Причем, абсолютно ничего такого в Nemerle нет, что помешало бы сделать это правильно — например, добавить аттрибут функциям, определяющий, пойдут они в "runtime" модуль или только в "macro module". И последний делать динамическим (это легко средствами Reflection.Emit делается). Получится вся статическая прелесть Nemerle, со всей его раздельной компиляцией, и при этом некий аналог image из Лиспов и Смоллтолков. Ничем за это платить не надо, никаких дополнительных накладных расходов, а вот возможностей это даст невообразимое количество.
Не стоит так вот запросто отмахиваться от опыта Лиспа только за то, что там скобочки и он динамический. У него всем остальным еще учиться и учиться.
O>> Я правильно понимаю, что в { ... } может быть произвольный императивный код? WH>Нет. Зачем?
На всякий случай. Потому как assert это только малая часть того, что можно (и нужно) делать с типами. Надо не только проверять корректность входных типов (они могут быть и неизвестными, быть привязанными к неотрезолвленной еще переменной), а уметь выводить новые уравнения для вывода типов, как минимум. И делать это только декларативно может оказаться неоправданно сложным.
WH>assert'ов и еще кое-чего достаточно. На их основе будет построен алгоритм вывода типов. WH>А в случае если вывод не удался, будет выдано соответствующее сообщение.
Еще одно проблемное место — такие сообщения очень непросто сделать понятными и разумными. Тот же Haskell ругается как портовый грузчик, так что сами разработчики его не всегда понимают. А если тут еще и макры со своей специфичной руганью влезут, то все, тушите свет, приплыли.
WH>Подход V8 круче. Он может больше вывести. Но всё равно до нормальной статики не дотягивает.
Для этого ему приходится делать чуть ли не полноценную абстрактную интерпретацию. С другой стороны, не так уж это и дорого.
O>> Да и не стоит забывать, что в .NET от RTTI все равно не избавишься, так почему бы им не пользоваться тогда? WH>Если его не трогать, то оно почти ничего не просит. WH>А если тронуть получишь просадку производительности в десятки раз.
Каким образом? Компилятору от RTTI много не надо. Узнать типы, сравнить типы на приводимость, и т.д.
WH>>>Ну так я и планирую ввести предметно ориентированные системы типов. O>> Для чего нужна самая базовая система типов, которая никаких ограничений не накладывает вообще. WH>Зачем?
Чтобы на нее можно было наложить любую возможную систему типов.
O>> А есть возражения? WH>Есть. Мне не известны компиляторы динамически типизированных языков, которые всегда могут вывести типы. Они все рано или поздно сваливаются в динамическую типизацию.
А для таких редких случаев можно опциональную статическую типизацию применять. Главное, чтобы она не была насильственной.
WH>Он может дать по рукам только когда код будет переписан в язык более низкого уровня. WH>Но эти ошибки я считаю ошибками разработчика макроса.
А он может дать по рукам за корректный, но нетипизируемый код. И именно этого и хотелось бы избежать.
WH>Те internal macro error. WH>И при обнаружении такой ошибки нужно чинить макрос. А не код, который его использует.
В том и фокус, что несовпадение типов далеко не всегда является ошибкой.
O>> Ну да, конечно же, SSA эквивалентен CPS. Только вот в SSA все намного короче и проще получается. WH>Да я не про CPS, а про обычные хвостовые вызовы.
Я про общий случай. В общем случае любую лапшу из goto элементарно привести к cps (через ssa).
O>> И зачем? С goto оптимизировать не надо, оно уже и так оптимально. WH>В него переписывать сложнее.
Да ну? Что вообще может быть проще чем метки и переходы?
WH>Особенно если иногда нужны не хвостовые вызовы и передача параметров.
Ну, необходимости хорошей оптимизации хвостовых вызовов наличие goto конечно же не отменяет.
WH>Можно конечно поизвращаться с организацией стека и глобальных для автомата переменных, но зачем, если это сделает компилятор языка более низкого уровня?
А если у нас и так уже достаточно низкоуровневая семантика? Зачем уровень поднимать?
Здравствуйте, Tanker, Вы писали:
O>> Про "все" я не говорил. Я привожу конкретный факт, в компиляторостроении полностью отсуствует связь между теорией и практикой. Факт объективный и тривиально доказуемый.
T>Боюсь тебя огорчить, но доказательств подобного в этом треде я не видел.
А если начать применять интеллект? Не пробовали?
T>>>Выдай эти два строки текста. Надеюсь их длина как в хорошей программе ограничена сотней символов ?
O>> Уже выдал, чуть раньше, про TRS и алгебру. Ничего кроме этого во всей этой области нет. Денотационные и операционные семантики? Чушь, сводится к TRS. Грамматики? Вообще нерелевантно. Оптимизации? На высоких уровнях сводится к правилам и стратегиям переписывания деревьев, на самых суровых низких уровнях (про которые большинству писателей компиляторов и знать-то не надо) немного сложнее, сводится к правилам и стратегиям переписывания DAG-ов.
T>Ну можно значит расслабиться, вся евклидова геометрия сводится к трём аксиомам и формальной логике. намёк понятен ?
До крайности идиотская аналогия. В геометрии полно всяких там теорем и прочей мути, без которой практические задачи решать невозможно.
А в компиляторах нет ни-че-го. Вообще. Никаких сущностей более высокого уровня чем тривиальные, очевидные переписывания.
Прекращайте уже спорить о "сложности" темы, про которую вы не знаете ровным счетом ничего. Ознакомьтесь с ней сначала, это легко и просто, а потом уже рассуждайте.
Здравствуйте, Tanker, Вы писали:
T>Простой фильтр. Дизайнер положил на форму галочки — кликаешь, появляются одни объекты. Еще кликаешь — появляются или исчезают другие. И тд.
Здравствуйте, Tanker, Вы писали:
O>> А не надо их брать. Я же сказал, это абсолютно иная тема, ничего общего с обсуждаемой не имеющая.
T>А где граница, что можно брать, а что нельзя ?
Ну, если вы до сих пор не смогли понять, о чем тут вообще разговор, то это печально.
O>> За последние лет двадцать я ни разу не сталкивался с необходимостью писать что либо на ассемблере. При том, что моя работа как раз тесно связана с HPC.
T>HPC не часто требует низкоуровневые оптимизации.
Ну-ну. В HPC часто требуется real time отклик и очень высокий throughput. Оптимизации там страшные. Но вот на ассемблере кодировать никто все равно не станет. Потому что в этом нет смысла, на ЯВУ можно добиться лучшей производительности чем с ассемблером.
T> А вот отрисовка простого контрола очень даже часто.
Даже не смешно.
O>> Что-то вы совсем зарапортовались. Что за нелепая аналогия? Я говорю о том, что сложность областей несопоставимая. Компиляторы — это тупо и примитивно, и изучается за несколько часов полностью. UI — гигантских размеров дисциплина, на поверхностное знакомство с которой могут уйти годы.
T>А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи.
Чушь. Они настолько примитивные, что никакого расхождения быть не может.
T> Соответсвено что одному просто, то другому будет сложно. А Колмгоров говорил совсем про другое.
Вы хотя бы отдаленное представление имеете о Колмогоровской сложности?
Здравствуйте, oldjackal, Вы писали:
T>>Боюсь тебя огорчить, но доказательств подобного в этом треде я не видел.
O> А если начать применять интеллект? Не пробовали?
Начни.
T>>Ну можно значит расслабиться, вся евклидова геометрия сводится к трём аксиомам и формальной логике. намёк понятен ?
O> До крайности идиотская аналогия. В геометрии полно всяких там теорем и прочей мути, без которой практические задачи решать невозможно.
Любая теорема выводится из трех аксиом с помощью формальной логики. Что бы решать задачи нужно этот навык довести до автоматизма. После этого спокойно можешь утверждать, что на всё хватит логики и трех аксиом
O> А в компиляторах нет ни-че-го. Вообще. Никаких сущностей более высокого уровня чем тривиальные, очевидные переписывания.
Напиши книгу, я куплю, почитаю.
O> Прекращайте уже спорить о "сложности" темы, про которую вы не знаете ровным счетом ничего. Ознакомьтесь с ней сначала, это легко и просто, а потом уже рассуждайте.
Так где же ознакомиться, если весь материал, что есть, по твоим словам негодны
Здравствуйте, oldjackal, Вы писали:
T>>Простой фильтр. Дизайнер положил на форму галочки — кликаешь, появляются одни объекты. Еще кликаешь — появляются или исчезают другие. И тд.
O> Я опять ни слова не понял.
Здравствуйте, vdimas, Вы писали:
V>Через встроенный ассемблер, вестимо.
Если у вас есть встроенный ассемблер, то аргумент про библиотеки не нужен. Если нету — то аргумент неприменим.
V>Но вообще, если программа, порождаемая языком, работает сверху ОС, то языку необходимо только умение подключать библиотеки и больше ничего, чтобы превратиться в язык общего назначения.
Мне не нравится этот критерий. Потому что он слишком сильно противоречит бытовому понятию DSL. Скажем, Clipper, который, в отличие от VBA, явно заточен на конкретный домен, получается GPPL, т.к. в нём можно подключать библиотеки.
V>Поэтому строгий DSL никак не сделаешь на основе языков, которые умеют это изкаробки.
Вот это опять непонятно. Что именно называется "это"? Наличие встроенных в языке средств импорта библиотек?
Да ну! Вот, скажем, в языке C нет никаких возможностей импорта библиотек. Там всё, что есть — это текст одной программы.
Библиотеки в него потом запихивает линкер, который отдельный от языка.
Давайте теперь я напишу версию лого, в синтаксис (и семантику) которого я добавлю IMPORT MODULE XXX. Он что, от этого внезапно станет GPPL? Возможность имитировать логовский модуль при помощи сторонних средств (а именно это и делается в тот момент, когда мы стряпаем библиотеку для С-программ на языках типа ассемблера) мне не кажется ключевой для осмысления этого. V>Но на JS или LUA прекрасно сделаешь.
Объясните мне ещё раз, чем С в этом смысле хуже JS.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, oldjackal, Вы писали:
T>>HPC не часто требует низкоуровневые оптимизации.
O> Ну-ну. В HPC часто требуется real time отклик и очень высокий throughput. Оптимизации там страшные. Но вот на ассемблере кодировать никто все равно не станет. Потому что в этом нет смысла, на ЯВУ можно добиться лучшей производительности чем с ассемблером.
Оптимизации есть, только высокоуровневые, а что бы не пришлось кодить на ассемблере проще взять готовое ядро которое умеет реалтаймную диспетчеризацию.
T>> А вот отрисовка простого контрола очень даже часто.
O> Даже не смешно.
T>>А я говорю про то, что у каждого практика в голове свои уникальные понятия и связи. O> Чушь. Они настолько примитивные, что никакого расхождения быть не может.
И поэтому ты через сообщение записывашь в дураки чуть не всех подряд ?
T>> Соответсвено что одному просто, то другому будет сложно. А Колмгоров говорил совсем про другое.
O> Вы хотя бы отдаленное представление имеете о Колмогоровской сложности?
Конечно, только я довожу до тебя простую мысль, которая никакого отношения к его сложности не имеет.
Здравствуйте, Tanker, Вы писали:
T>Если времени не хватает даже на формализацию, то хоть ДСЛ, хоть его отсутствие ничем тебе не поможет и есть сомнения, что ДСЛ будет работать при отсутствии качетсвенной формализации.
Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.
T> Например потому, что придется вводить десяток другой дсл для частных задач и организовывать взаимодействие этих дсл.
И именно такой подход к быстрому прототипированию и работает быстрее и надежнее всех прочих. Вы не знали?
T>>>Не надо передёргивать. 10% это процент расходов на всех разработчиков. Т.е. сумма ЗП разрабов за период поделить на бюджет и помножить на 100. WH>>И на что же тратятся остальные 90%. Похоже у вас там воруют. Либо просто управленцы дураки. WH>>Это конечно если мы про контору, которая чисто разработкой живет, говорим.
T>90% это управление и маркетинг. Ты вообще в курсе, что маркетинг увеличивает выхлоп каждого девелопера в десятки а то и сотни раз ?
Расстреливать таких манагеров, которые привлекают к "управлению и маркетингу" инженеров. Каждый сверчок должен знать свой шесток. Программисты должны программировать, 100% рабочего времени.
T>Жалко, людей вроде тебя не нашлось в UI лет 40 назад, а то уже был бы один грамотный дсл для всех случаев в UI.
Так никто и не объяснил, на кой нужен "один" DSL "для всех случаев". Да еще и в UI. Это в корне противоречит самой идее DSL.
WH>>>>Тех, кто не учиться нужно, отправлять в дворники, а не программистом брать. T>>>Я только за. Предложи хорошее решение. WH>>Не брать. В чем проблема то?
T>Проблема в том, что кого то брать нужно. А людей с ростом квалификиции крайне мало, при чем это сильно нелинейная зависимость.
Вы преувеличиваете. Большинство программистов достаточно умны. Раз уж они ООП осилили, то уж намного более простую методологию с DSL осилят без проблем.
T>Приходи с такими цифрами к CEO какого нибудь софтверного гиганта. Если у тебя все получится, в ближайшие 10 лет увидим адский прорыв. Правильно ?
Что-то я не видел, чтобы гиганты набирали идиотов. Там как раз все сурово. Идиоты в основном кучкуются в больших аутсорсинговых конторах в некоторых всем известных странах.
Здравствуйте, Vain, Вы писали:
S>>Складывается ощущение, что вы мне пытаетесь доказать, что можно заменить запрос на SQL процедурой на C++, причём последняя будет иметь сопоставимую с запросом сложность. Но этого не может быть, так как это, очевидно, неверно. V>Не так, в sql много чего кроме самих запросов. На самом деле сами запросы это вершина айсберга. Можно взять любой учебник по SQL и поисследовать на тему что ещё входит в "знания по SQL".
Ещё раз спрошу: какой тезис вы пытаетесь доказать или оспорить? Вам что, кто-то тут написал, что SQL — проще, чем С++?
Нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tanker, Вы писали:
T> Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.
Ну, то есть парсер СSV на string.split нагнулся, теперь вы перешли на tab-delimited values.
Я рад, что мы хотя бы прояснили вопросы о фатальных недостатках парсеров, построенных на string.split. Второй вариант, который вам известен, я так понял — регексы, да?
Так вот: они — тоже не работают. Работают парсеры, честно построенные на стейт-машине. У них всё в порядке с быстродействием и надёжностью. Плохо у них только с объёмом ручного кода. DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tanker, Вы писали:
O>> Поразительная упертость. Включите мозг! Практика лет 60 существует. Компиляторы всех мастей пишут, не напрягаясь. Наплевав на рассуждения теоретиков. Никаких сложностей и неясных моментов в практике нет уже очень давно. А теоретики как рассуждали про "формальные грамматики", как спорили про разницу между LALR(1) и SLR, так и спорят, тогда как абсолютно все практики всегда пишут ad hoc рекурсивные парсеры и знать не желают про баталии дебилов-теоретиков.
T>Да хоть сто лет, хоть тысячу. Преобразование опыта в теорию годную для распространения невозможно уложить в фиксированые сроки.
Опять глупости говорите. Несусветные глупости. Ну явно не имеете понятия о Колмогорове и его сложности.
Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.
O>> Советую прежде чем продолжать этот нелепый спор, где вы заведомо и на все 100% лажаетесь, посмотрите на существующие промышленные компиляторы. Попробуйте найти там хотя бы малюсенький след того, о чем рассуждают дебилы-теоретики. Найдите там хотя бы одну страницу драконьей книги, на которую теоретики молятся. Не найдете! Ни в gcc, ни clang/llvm, ни в HotSpot, ни в CPython, нигде!
T>Зато знания уложеные в гцц невозможно распространять.
Можно. Элементарно. Один из разработчиков gcc несколько лет назад объяснил мне про ssa на пальцах. За пять минут. Хватило. А это, пожалуй, самое сложное что там есть. Остальное из чтения исходников понимается легко и непринужденно.
T> А книгу драконо — можно, хотя и сложно.
Может и "можно", но не нужно. Ее по хорошему следовало бы признать экстремистской и запретить.
O>> Нет никакой связи между теоретиками и практикой. И не будет никогда. Теоретики не собираются обобщать практический опыт, потому как он и не нуждается в их нелепых услугах, да и противоречит всему тому, во что они слепо верят.
T>Связь есть но не там где ты хочешь видеть.
Конкретика где? Такая-то страница дракона, применена в таких-то и таких-то исходных файлах gcc. Без этого все, что вы говорите — пустой треп.
O>> Это от того, что вы далеки от темы и не имеете представления ни о том, что там накалякали теоретики, ни о том, чем реально пользуются практики. Советую ознакомиться, тогда вы будете вынуждены согласиться с моимим обобщениями.
T>У каждого практика в голове свой набор понятий и связей. Что бы эти понятия стали общими, нужны теоретики.
Нужно живое общение между практиками. Общие понятия рождаются сами, без помощи высоколобых теоретиков.
O>> Мне было бы очень интересно узнать, где можно взять других?
T>На рынке труда, где и все.
Назовите учебные заведения, откуда выходят ваши гении. И помните, мы говорим только о тех, кто только-только попал на рынок труда, у кого ни капли опыта нет.
Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.
Здравствуйте, oldjackal, Вы писали:
O> Расстреливать таких манагеров, которые привлекают к "управлению и маркетингу" инженеров. Каждый сверчок должен знать свой шесток. Программисты должны программировать, 100% рабочего времени.
Не, он не про это. Он про то, что кроме инженеров, у компаний есть и другие источники затрат. Скажем, чтобы твой продукт купили, нужно оплачивать расходы на маркетинг. Руководству компании эффективность труда одного подразделения, пусть даже и самого важного, важна пропорционально доле ФОТ этого подразделения в бюджете компании.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tanker, Вы писали:
O>> Затем, что иначе это не будет поддежкой CSV. Потому как валидный CSV поломает этот "парсер" запросто. T>правильно. Поддержка CSV ради поддержки CSV не нужна. Задача решена — парсер не нужен. А решена ли задача или нет, проверяет и определяет человек из бизнеса.
Ты говоришь противоположные вещи.
Если система должна разбирать формат CSV, то есть на вход может поступить любой CSV-файл, то string.split явно не достаточно, и пример подбирается легко. И спорить с этим бессмысленно.
Другое дело, что во множестве систем для передачи данных может использоваться другой формат, условно назовем его CSVlite, который описывается как "Текстовые поля, разделенные запятой. Значения полей не могут содержать запятой или перевода строки". На него отлично ложатся матрицы целых чисел, например. Этот формат часто путают с CSV, но это ошибка, это другой формат, подмножество CSV. И разбирать его действительно гораздо проще.
