Здравствуйте, Sinclair, Вы писали:
T>> Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов. S>Ну, то есть парсер СSV на string.split нагнулся, теперь вы перешли на tab-delimited values.
Не мы, но да.
S>Я рад, что мы хотя бы прояснили вопросы о фатальных недостатках парсеров, построенных на string.split. Второй вариант, который вам известен, я так понял — регексы, да?
Да где ж фатальный, если задача выполняется ? Код наверное 20 лет проработал
S>Так вот: они — тоже не работают.
Почему не работают ? По секрету, я не разбирался, где можно было, менял на свой собственный. Я вообще очень не люблю регулярные выражения для случаев больших чем всякие токены.
Здравствуйте, Tanker, Вы писали:
O>> Сформулированная задача — это уже формализованная задача. По определению. А если задачу даже сформулировать не осилили, то уж и закодировать решение в лоб никто не сможет.
T>Я сколько ни работаю, все время все приходится формулировать и формализовывать самому
Что, и задачи себе самому придумывать приходится? Сам пошутил, сам посмеялся?
T>>> Например потому, что придется вводить десяток другой дсл для частных задач и организовывать взаимодействие этих дсл. O>> И именно такой подход к быстрому прототипированию и работает быстрее и надежнее всех прочих. Вы не знали?
T>Покажи пример.
Или вот: http://homepage.mac.com/digego/study_in_keith.mov
T>Еще раз — на проект затрачена определенная сумма, которая кроме зп всех вовлеченных (разрабы, тестеры, маркетинг, менеджмент и тд) включает в себя и аренду, и железо и командировки и все возможные налоги и вызов девок для празднования майлстонов. T>ЗП(гросс) всех разрабов вместе с тестерами это 10% от всей суммы.
Да кого это колышет-то? Вы-то сначала про время чего-то там говорили.
T>Вроде умные люди, а азы экономики понять не могут С т.з. бизнеса нужно или урезать затраты наибольшей части, 90% или же делать так, что бы общий расклад приносил денег больше. Второй вариант это норма для софтверной индустрии.
Вот не надо мне про экономику заливать. Не интересно мне выслушивать про экономику от человека, не понимающего смысла "time to market".
O>> Так никто и не объяснил, на кой нужен "один" DSL "для всех случаев". Да еще и в UI. Это в корне противоречит самой идее DSL.
T>Ну то есть, для распознавания aaa ты используешь регулярные выражения, а для ббб тебе вдруг понадобится другой мощный механизм ? Я даже не знаю, что и сказать.
Как-то так. Для распознавания регулярной грамматики я буду использовать один DSL (регулярные выражения), для распознавания контекстно-свободной грамматики — совсем другой (например, PEG). Вся идея DSL в том, что надо решать конкретные частные задачи, а не искать ненужные в данный момент обобщения. Для обобщений есть языки "общего назначения". Те самые, которые не нужны вовсе.
T>>>Проблема в том, что кого то брать нужно. А людей с ростом квалификиции крайне мало, при чем это сильно нелинейная зависимость. O>> Вы преувеличиваете. Большинство программистов достаточно умны. Раз уж они ООП осилили, то уж намного более простую методологию с DSL осилят без проблем.
T>Не я преувеличиваю, а ты сам только что плакался, что не можешь найти толкового студента-выпускника.
Я где-то говорил, что они глупые и "не толковые"? Я говорил, что они не умеют программировать, и что ничему хорошему их преподаватели не научили. Но это не беда, дурное дело не хитрое, быстро научить можно. Программирование вообще тривиально, если не переусложнять его искусственно всякими там ООПами да паттернами.
T> Но почему то простую истину про корреляцию разницы в квалификации с доступностью на рынке труда доказываю тебе именно я, хотя плачешься именно ты.
Я не спорю, что есть корреляция. Разница в том, что я устанавливаю планку намного ниже. Как по мне, если человек fizz-buzz смог закодить, то он уже адекватный программист. И компиляторы писать научится без проблем. Вы же утверждаете, что это только редкие высокооплачиваемые ковбои могут, что есть чушь и бред, и опровергается практикой.
T>>>Приходи с такими цифрами к CEO какого нибудь софтверного гиганта. Если у тебя все получится, в ближайшие 10 лет увидим адский прорыв. Правильно ? O>> Что-то я не видел, чтобы гиганты набирали идиотов. Там как раз все сурово. Идиоты в основном кучкуются в больших аутсорсинговых конторах в некоторых всем известных странах.
T>Не далее чем пару сообщений назад ты назвал людей из конторы-гиганта идиотами.
Это софтовая контора? Не верю. В софтовой конторе такого быть не может. Не представляю себе Microsoft или Google, где парсили бы CSV сплитом. А в не-софтовых, конечно же, любой дряни хватает.
Здравствуйте, oldjackal, Вы писали:
T>>Да хоть сто лет, хоть тысячу. Преобразование опыта в теорию годную для распространения невозможно уложить в фиксированые сроки.
O> Опять глупости говорите. Несусветные глупости. Ну явно не имеете понятия о Колмогорове и его сложности.
Колмгоровская сложность не имеет никакого отношения к тому что я говорю.
O> Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.
Это заблуждение.
T>>Зато знания уложеные в гцц невозможно распространять.
O> Можно. Элементарно. Один из разработчиков gcc несколько лет назад объяснил мне про ssa на пальцах. За пять минут. Хватило. А это, пожалуй, самое сложное что там есть. Остальное из чтения исходников понимается легко и непринужденно.
Это пример того, почему знания уложеные в гцц распространять невозможно. Когда понадобится дать такой материал студентам ты первый скажешь что преподаватель баран, хотя это будет тот же разработчик гцц
T>>Связь есть но не там где ты хочешь видеть.
O> Конкретика где? Такая-то страница дракона, применена в таких-то и таких-то исходных файлах gcc. Без этого все, что вы говорите — пустой треп.
Как минимум регулярные грамматики используются и в гцц
T>>У каждого практика в голове свой набор понятий и связей. Что бы эти понятия стали общими, нужны теоретики.
O> Нужно живое общение между практиками. Общие понятия рождаются сами, без помощи высоколобых теоретиков.
Нужно, но это неразрешимая задача. Разработчик гцц про которого ты упомянул, просто не выдержит паломничество студентов всех времен и народов. Придется родить книгу. Тут то он и превратится в высоколобого теоретика.
T>>На рынке труда, где и все.
O> Назовите учебные заведения, откуда выходят ваши гении. И помните, мы говорим только о тех, кто только-только попал на рынок труда, у кого ни капли опыта нет.
Все заведения по ИТ в странах бывшего СССР которые были созданы во времена этого СССР.
O> Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.
Ни один вуз не отменяет самостоятельной работы. Ты хотел как то иначе ?
Здравствуйте, fmiracle, Вы писали:
F>Ты говоришь противоположные вещи. F>Если система должна разбирать формат CSV, то есть на вход может поступить любой CSV-файл, то string.split явно не достаточно, и пример подбирается легко. И спорить с этим бессмысленно.
Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.
F>Другое дело, что во множестве систем для передачи данных может использоваться другой формат, условно назовем его CSVlite, который описывается как "Текстовые поля, разделенные запятой. Значения полей не могут содержать запятой или перевода строки". На него отлично ложатся матрицы целых чисел, например. Этот формат часто путают с CSV, но это ошибка, это другой формат, подмножество CSV. И разбирать его действительно гораздо проще.
Здравствуйте, Tanker, Вы писали:
O>> Опять глупости говорите. Несусветные глупости. Ну явно не имеете понятия о Колмогорове и его сложности.
T>Колмгоровская сложность не имеет никакого отношения к тому что я говорю.
Имеет. Непосредственное. Алгоритмическая теория информации, собственно, и описывает, как эмпирические знания превращаются в теорию. Вы и этого не понимаете? Жаль.
O>> Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.
T>Это заблуждение.
Это факт. Железный. Опровергните, если можете — найдите чего-то, чего практики не знают, что появилось лишь недавно. И найдите хотя бы один след из того, что обобщено практиками (и далекими от драконьей доминирующей школы теоретиками) в "официальных" учебниках и курсах по компиляторам.
T>Это пример того, почему знания уложеные в гцц распространять невозможно. Когда понадобится дать такой материал студентам ты первый скажешь что преподаватель баран, хотя это будет тот же разработчик гцц
Это дают студентам. Легко. И они понимают. Только вот драконовская школа к этом непричастна.
O>> Конкретика где? Такая-то страница дракона, применена в таких-то и таких-то исходных файлах gcc. Без этого все, что вы говорите — пустой треп.
T>Как минимум регулярные грамматики используются и в гцц
Далеко не так явно. Там даже лексер рукописный. Никаких генераторов.
O>> Нужно живое общение между практиками. Общие понятия рождаются сами, без помощи высоколобых теоретиков.
T>Нужно, но это неразрешимая задача. Разработчик гцц про которого ты упомянул, просто не выдержит паломничество студентов всех времен и народов. Придется родить книгу. Тут то он и превратится в высоколобого теоретика.
В теоретика он не превратится. Его диссертация опубликована, все ею пользуются, кому надо — http://www.cri.ensmp.fr/classement/doc/A-381.pdf
T>>>На рынке труда, где и все.
O>> Назовите учебные заведения, откуда выходят ваши гении. И помните, мы говорим только о тех, кто только-только попал на рынок труда, у кого ни капли опыта нет.
T>Все заведения по ИТ в странах бывшего СССР которые были созданы во времена этого СССР.
Это какие же такие заведения "по ИТ" были созданы во времена СССР?!?
O>> Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.
T>Ни один вуз не отменяет самостоятельной работы. Ты хотел как то иначе ?
Я то как раз не хотел. Это вы тут втираете, что преподватели могут чему-то там научить. А я же утверждаю, что в программировании научить может только практика. Да и не только в программировании. Причем в программировании теория как правило только мешает, и как правило никакой связи с практикой не имеет.
Здравствуйте, oldjackal, Вы писали:
T>>Любая теорема выводится из трех аксиом с помощью формальной логики. Что бы решать задачи нужно этот навык довести до автоматизма. После этого спокойно можешь утверждать, что на всё хватит логики и трех аксиом
O> Путь от аксиом до решения задачи может быть очень длинным. Путь от неформального описания языка к компилятору этого языка в другой язык, немного более низкого уровня — тривиальный, в один шаг. Сравнивать нельзя.
А мне тож самое учитель геометрии доказывал — решение любой задачи делается в один шаг
T>>Напиши книгу, я куплю, почитаю.
O> Может мне еще и про "2+2=4" и про "Hello, World!" написать? Сопоставимые по сложности темы.
Предполагается, что ЦА искаропки знает функциональщину ? Ты только что говорил, что студенты на выходе не умеют программировать и тут же выдаёшь в качетсве хорошей ссылки материал, который эти студенты по твоим же словам не в состоянии осилить.
O>так же неплохо: http://llvm.org/docs/tutorial/
В качетсве методички для лабораторных сгодится.
O> А так же одна из глав SICP. Он вообще весь малость затянутый, там все мелочи разжевывают многократно, но относительно компиляции они палку не слишком сильно перегибают.
Сам подумай — студенты, как ты плачешься, программировать неумеют, а ты им SICP хочешь вручить.
Здравствуйте, oldjackal, Вы писали:
T>>Оптимизации есть, только высокоуровневые, а что бы не пришлось кодить на ассемблере проще взять готовое ядро которое умеет реалтаймную диспетчеризацию.
O> Вы опять с умным видом рассуждаете о теме, в которой ни бум-бум. Лучше про "фильтры" и контроллы рассуждайте, это явно ваш конек. O> Какая такая "диспетчеризация"?
Самая обыкновенная.
>Часто вообще никакой ОС нет, все на голом железе живет.
А что, диспетчеры только в ОС бывают ?
>И нужно уместить довольно сложные вычисления в заданное количество миллисекунд, любыми путями. Казалось бы, как раз для ассемблера задача — ан нет, на C быстрее получается. Нельзя человеку соревноваться с современными компиляторами, компиляторы умнее.
Попробуй ядро диспетчера реализовать без ассемблера. Чуть более чем все реалтаймные диспетчеры содержат ассемблерный код. Потому ядро и берется готовым, что бы дальше пилить на ЯВУ.
O> Не всех. Только дураков. А их очень мало. Это вы тут распинаетесь, что мол все программисты тупые и ничего сложнее string.split никогда не осилят, а у меня есть все основания вам не верить, мне дураки редко попадаются.
Ты противоречишь своим же собственным словам Забыл что ли, как плакался про студентов и молодых специалистов ?
T>>Конечно, только я довожу до тебя простую мысль, которая никакого отношения к его сложности не имеет.
O> Мне абсолютно не интересны ваши нерелевантные простые мысли. Мы обсуждали сравнение сложности двух предметных областей.
Судя по примеру транслятора схемы в си, ты соврешненно не понимаешь о чем речь.
Здравствуйте, Tanker, Вы писали:
O>> Путь от аксиом до решения задачи может быть очень длинным. Путь от неформального описания языка к компилятору этого языка в другой язык, немного более низкого уровня — тривиальный, в один шаг. Сравнивать нельзя.
T>А мне тож самое учитель геометрии доказывал — решение любой задачи делается в один шаг
Он врал. А я правду говорю. В компиляторах если и встречаются неочевидные преобразования, то только от глупости разработчиков. По всем правилам их быть просто не должно.
O>> Что, кроме драконьей книги ничего нет? Вранье. Полно отличного материала. Одно из лучших, что я видел:
O>>http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/90-min-scc/90-min-scc.pdf
T>Предполагается, что ЦА искаропки знает функциональщину ?
Если и не знает, то разберется. Это ж не ООП какой, тут думать не надо.
T> Ты только что говорил, что студенты на выходе не умеют программировать и тут же выдаёшь в качетсве хорошей ссылки материал, который эти студенты по твоим же словам не в состоянии осилить.
Так и хорошо, что не умеют программировать. Мозги не испорченные. Осилят самостоятельно за кратчайшее время. Я еще не встречал таких, кто даже тупейшую Схему не осиливает. Это ж не шарп какой.
O>>так же неплохо: http://llvm.org/docs/tutorial/
T>В качетсве методички для лабораторных сгодится.
Ничего более сложного в жизни и не надо. Да и Kaleidoscope сложноват, сложнее чем 99% DSL.
O>> А так же одна из глав SICP. Он вообще весь малость затянутый, там все мелочи разжевывают многократно, но относительно компиляции они палку не слишком сильно перегибают.
T>Сам подумай — студенты, как ты плачешься, программировать неумеют, а ты им SICP хочешь вручить.
SICP как раз и есть книга для тех, кто не умеет программировать и хочет научиться. Учебник для первокурсников.
Здравствуйте, fmiracle, Вы писали:
F>Я помню в школе у нас учительница преподавала химию и было все просто и понятно. Потом она переехала, вместо нее пришел новы преподавать, и сразу резко стало сложно и непонятно. Хотя сложность предмета при этом явно не изменилась.
А у меня было так — один и тот же преподаватель рассказывал про программирование и компиляторы и про ОС и много чего еще. Что странно, компиляторы в среднем давали худший выхлоп.
Здравствуйте, Tanker, Вы писали:
F>>Ты говоришь противоположные вещи. F>>Если система должна разбирать формат CSV, то есть на вход может поступить любой CSV-файл, то string.split явно не достаточно, и пример подбирается легко. И спорить с этим бессмысленно. T>Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.
Ну да. Ничего не зная про некоторый формат Х, они делают импорт из другого формата, лишь частично совпадающего с указанным, и гордо называют это "импорт из Х".
F>>Другое дело, что во множестве систем для передачи данных может использоваться другой формат, условно назовем его CSVlite, который описывается как "Текстовые поля, разделенные запятой. Значения полей не могут содержать запятой или перевода строки". На него отлично ложатся матрицы целых чисел, например. Этот формат часто путают с CSV, но это ошибка, это другой формат, подмножество CSV. И разбирать его действительно гораздо проще.
T>См выше
Во-во. Почитай внимательно, что я тебе написал. Я уж как мог разжевал. Да, на практике задача решена, и это прекрасно. Но чтобы не путать окружающих не надо говорить, что эта задача — импорт из CSV. Это импорт из совсем другого формата.
Мне, как бы, тоже не раз приходилось на практике импортировать из "файла с разделителями". Причем приходилось сталкиваться и со случаями, когда достаточно было string.split делать, и когда его было совершенно недостаточно. Вторые, кстати, чаще встречались. Когда в тексте идут всякие там адреса в произвольной форме или пользовательские комментарии — там в них может быть все что угодно, и запятые, и ; и табы, и все прочее.
Здравствуйте, oldjackal, Вы писали:
T>>Колмгоровская сложность не имеет никакого отношения к тому что я говорю.
O> Имеет. Непосредственное. Алгоритмическая теория информации, собственно, и описывает, как эмпирические знания превращаются в теорию. Вы и этого не понимаете? Жаль.
А я говорю про квалификацию программистов и уровень базовых знаний. Тебя послушать, так оказывается что любой студент априори не умеет программировать но почему то ему под силу фукнциональщина и он может прочтя две строчки текста (которые ты так и не выдал) сварганить компилятор для ДСЛ любой сложности.
O>>> Обобщенная теория всегда появляется тотчас же, как только набирается достаточный объем эмпирического знания. А поскольку нового эмпирического знания в обсуждаемой теме уже много лет нет, то можно уверенно говорить, что тема насытилась и ничего нового уже не будет. Мы знаем все.
T>>Это заблуждение.
O> Это факт. Железный. Опровергните, если можете — найдите чего-то, чего практики не знают, что появилось лишь недавно. И найдите хотя бы один след из того, что обобщено практиками (и далекими от драконьей доминирующей школы теоретиками) в "официальных" учебниках и курсах по компиляторам.
На примере ньютоновской механии и релативистской — годится ? Напомнить разницу во времени ? На примере геометрии евклида и лобачевского ?
T>>Это пример того, почему знания уложеные в гцц распространять невозможно. Когда понадобится дать такой материал студентам ты первый скажешь что преподаватель баран, хотя это будет тот же разработчик гцц
O> Это дают студентам. Легко. И они понимают. Только вот драконовская школа к этом непричастна.
тебе нельзя верить. Ты сказал, что студенты ничего не умеют. А сейчас сообщаешь обратное.
T>>Как минимум регулярные грамматики используются и в гцц O> Далеко не так явно. Там даже лексер рукописный. Никаких генераторов.
А что, книга дракона заставляет писат нерукописные лексеры или же там лексер не имеет отношения к регулярным грамматикам ?
T>>Нужно, но это неразрешимая задача. Разработчик гцц про которого ты упомянул, просто не выдержит паломничество студентов всех времен и народов. Придется родить книгу. Тут то он и превратится в высоколобого теоретика.
O> В теоретика он не превратится. Его диссертация опубликована, все ею пользуются, кому надо — http://www.cri.ensmp.fr/classement/doc/A-381.pdf
Значит уже превратился. Уже появилась диссертация которая будет покруче книги дракона, а ты сообщал вроде про "пять минут" или хочешь пересмотреть показания ?
T>>Все заведения по ИТ в странах бывшего СССР которые были созданы во времена этого СССР.
O> Это какие же такие заведения "по ИТ" были созданы во времена СССР?!?
Все заведения которые сейчас готовят специалистов по ИТ но при этом были созданы во времена СССР.
O>>> Все, кого я видел из МГУ, МФТИ, СПбГУ и прочих "крутых" ВУЗов не умели ничего, если только не учились вне ВУЗа.
T>>Ни один вуз не отменяет самостоятельной работы. Ты хотел как то иначе ?
O> Я то как раз не хотел. Это вы тут втираете, что преподватели могут чему-то там научить.
Буквально "учат" только учителя в начальной школе.
>А я же утверждаю, что в программировании научить может только практика. Да и не только в программировании. Причем в программировании теория как правило только мешает, и как правило никакой связи с практикой не имеет.
Есть люди двух типов. Одни умеют пользоваться теорией, другие — нет.
Здравствуйте, oldjackal, Вы писали:
O> Это слишком крупные уровни. Неинтересно. Иерархии языков не получится.
Получается.
WH>>И все они живут в разных ДЛЛ. WH>>Добавить новые уровни не проблема. O> И по dll на уровень? У меня сотни уровней бывают.
Сотни? Откуда?
Или ты то, что я делаю функцией делаешь макрой?
Так тоже можно, но я о том и говорю что это другой подход.
O>>>Ничем за это платить не надо, WH>>Тормозами. O> Откуда тормоза?!?
Из постоянной динамической компиляции или интерпретации.
O>Все таки вы до сих пор не понимаете.
Я прекрасно понимаю то, как работает лисп.
Просто я работаю иначе.
O> Да нет же, не умеет! Я не смогу раскрыть макру в код, определяющий другую макру, которая в следующей же строке и будет использована. Тем более я не смогу раскрыть макру в код, определяющий другую макру и код, эту другую макру использующий. А все это совершенно необходимо для реализации DSL в виде последовательности малых преобразований.
Макры генерирующие обращения к другим макрам это понятно. И в моей схеме это возможно.
Но макры генерирующие новые макры?
Не понимаю, зачем оно надо.
WH>>Так эти уравнения будут выведены и assert'ов. WH>>В этом вся идея. O> Это уже очень существенное ограничение.
Почему?
O> Это простейший случай. В жизни все сложнее.
Посмотрим что получится.
O> Например, чтобы при раскрытии макры знать, какие методы есть у объектов этого типа.
Это и по-другому сделать можно.
O> Ну как зачем? Если мы преобразуем DSL в язык более низкого уровня, то его система типов должна так же преобразовываться в систему типов целевого языка.
Преобразование может быть очень не прямым.
O>>> В том и фокус, что несовпадение типов далеко не всегда является ошибкой. WH>>А для меня всегда. O> То есть, Y-комбинатора не существует?
То есть существуют системы типов, в которых можно его типизировать.
O> Свою работу можно так и строить (хоть это и уныло).
Вот тут у нас принципиальное противоречие.
Я иначе работать не могу.
O>Но вот пытаться семантику всех-всех возможных DSL засунуть в это прокрустово ложе это уже опасно.
Не думаю.
Более того я уверен что предметно ориентированные системы типов будут очень хорошим помощником.
O> А если мы их добавим, то это уже совсем другой уровень, не тот, на котором goto нужны..
Вот я и говорю что они только на самых низких уровнях и нужны.
O> С чего вдруг? Мне проще всего скомпилировать FSM в кучу меток и goto. Если я из него буду switch делать, то это уже усложнение.
А если взаимно-рекурсивные функции, то код получится почти 1 в 1.
Но если вдруг понадобится усложнить и где-то добавить не хвостовую рекурсию или аргументы к функции, то проблем не будет.
O>Семантика goto идеально подходит к семантике перехода между состояниями в FSM. При этом уровень языка в обработчиках состояний может быть сколь угодно высоким.
Точно также FSM ложится и на взаимно-рекурсивные функции.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Tanker, Вы писали:
F>>Я помню в школе у нас учительница преподавала химию и было все просто и понятно. Потом она переехала, вместо нее пришел новы преподавать, и сразу резко стало сложно и непонятно. Хотя сложность предмета при этом явно не изменилась. T>А у меня было так — один и тот же преподаватель рассказывал про программирование и компиляторы и про ОС и много чего еще. Что странно, компиляторы в среднем давали худший выхлоп.
Ну он же не биоробот, идеально заточенный под преподавание всего? Может быть, компиляторостроение ему была не интересная тема просто
Вообще, у нас тоже компиляторы и грамматики преподавали как-то так себе. У меня после этого так полный сумбур и непонятность и осталась в голове Но непонятная подача материалами еще не значит, что его в принципе невозможно подавать проще.
Здравствуйте, Sinclair, Вы писали:
V>>Ну, предположим, операции над примитивами реляционной алгебры, выраженными в некоторых структурах данных, я напишу. Так же как транзакции, и чего? S>Покажите код, который будет пользоваться этими операциями. S>Скажем, аналог S>
S>select Manager.Name, OrderTotals.Amount
S>from Manager
S>inner join City on City.ID = Manager.CityID
S>inner join
S> (select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID)
S> OrderTotals on OrderTotals.ManagerID = Manager.ID
S>where City.Name like 'Н%'
S>order by 2 desc
S>
До получения кода надо получить набор операций в терминах РА. Я не так давно тебе уже показывал как это делается и как это выглядит. (если настаиваешь, поищу ссылку).
После этого подставляешь имеющиеся алгоритмы, реализующие примитивы РА над нужными структурами, в которых хранятся данные сущностей Manager, City и прочих. Сами алгоритмы могут быть как энергичными, так и ленивыми на итераторах...
Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.
V>>Матан — это не теоремы, это исследование ф-ий и их систем. S>Он про другой матан.
Это он тебе сам сказал?
Таким макаром можно далеко пойти, называя матаном любую формальную модель... даже если это модель табурета.
Здравствуйте, fmiracle, Вы писали:
T>>Так и думают теоретики. Практики понимают, что задача сводится к импорту данных кастомера и импортируют даже ничего не зная про CSV. Собтсвенно string.split это однозначно доказывает.
F>Ну да. Ничего не зная про некоторый формат Х, они делают импорт из другого формата, лишь частично совпадающего с указанным, и гордо называют это "импорт из Х".
Главное что задача решена и бизнес доволен.
T>>См выше
F>Во-во. Почитай внимательно, что я тебе написал. Я уж как мог разжевал. Да, на практике задача решена, и это прекрасно. Но чтобы не путать окружающих не надо говорить, что эта задача — импорт из CSV. Это импорт из совсем другого формата.
Я все это понимаю. Если ты плохо читаешь, я на вский напишу еще раз, что этот же вопрос я сам же и пытался решать, т.е. вместо string.split ввести CSV-парсер.
Здравствуйте, oldjackal, Вы писали:
T>>А мне тож самое учитель геометрии доказывал — решение любой задачи делается в один шаг
O> Он врал. А я правду говорю. В компиляторах если и встречаются неочевидные преобразования, то только от глупости разработчиков. По всем правилам их быть просто не должно.
Конечно врал, точно так же как и ты. Говорил про две строчки текста и "пять минут", а на поверку выдал три источника ЦА которых как минимум должна знать функциональщину и понимать диссеры написаные языком почище чем в книге дракона.
T>>Предполагается, что ЦА искаропки знает функциональщину ?
O> Если и не знает, то разберется. Это ж не ООП какой, тут думать не надо.
Это в ООП думать не надо
T>> Ты только что говорил, что студенты на выходе не умеют программировать и тут же выдаёшь в качетсве хорошей ссылки материал, который эти студенты по твоим же словам не в состоянии осилить.
O> Так и хорошо, что не умеют программировать. Мозги не испорченные. Осилят самостоятельно за кратчайшее время. Я еще не встречал таких, кто даже тупейшую Схему не осиливает. Это ж не шарп какой.
тогда природа твоего вайна не ясна.
T>>Сам подумай — студенты, как ты плачешься, программировать неумеют, а ты им SICP хочешь вручить.
O> SICP как раз и есть книга для тех, кто не умеет программировать и хочет научиться. Учебник для первокурсников.
От него отказались в МИТ как от устаревшего материала.
Здравствуйте, fmiracle, Вы писали:
F>Ну он же не биоробот, идеально заточенный под преподавание всего? Может быть, компиляторостроение ему была не интересная тема просто
Компиляторы это его основное направление работы. Этими компиляторами он зарабатывал деньги еще большие чем преподавание в институте.
F>Вообще, у нас тоже компиляторы и грамматики преподавали как-то так себе. У меня после этого так полный сумбур и непонятность и осталась в голове Но непонятная подача материалами еще не значит, что его в принципе невозможно подавать проще.
А я разве где то утверждаю, что в принципе невозможно проще ?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Tanker, Вы писали:
T>> Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов. S>Ну, то есть парсер СSV на string.split нагнулся, теперь вы перешли на tab-delimited values. S>Я рад, что мы хотя бы прояснили вопросы о фатальных недостатках парсеров, построенных на string.split. Второй вариант, который вам известен, я так понял — регексы, да? S>Так вот: они — тоже не работают. Работают парсеры, честно построенные на стейт-машине. У них всё в порядке с быстродействием и надёжностью. Плохо у них только с объёмом ручного кода. DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.
К слову — запятая является разделителем целой и десятичной части в очень большом числе стран (к примеру, в Европе практически все кроме Британии с Ирландией её используют)
Здравствуйте, alex_public, Вы писали:
_>Краем уха слышал, что там ещё некий Lazarus набирает силу. )
Ну вроде да, народ Lazarus-ом пользуется (на Delphi он похож, но не полностью совместим). И вообще, FreePascal хорошая штука. Он конечно по оптимизациям и всякой эффективности уступает C++, но если ничего сверхсерьёзного не нужно, скажем, какая-то утилита, особенно кроссплатформенная, то на нём на порядок проще и быстрее реализовать, чем на С++. Кстати, у него удобные и реально кроссплатформенные модули для работы с консолью, чем мучения в С++, с его всяким ncurses, особенно с портами на другие платформы.
А лично я от программирования в GUI-дизайнере как-то уже отошёл в сторону. Всё-таки неудобно, когда ты не видишь в виде удобного (!) кода то, чего создаешь, что изменяешь (дельфовские DFM-файлы — они не для этого), есть неудобное разделение — что-то нужно делать в дизайнере (в которых ковыряться мало удовольствия), а что-то нужно в коде ваять. К тому же дизайнерство ограничивает тебя в функционале, потенциале, несмотря на то, что например, в Delphi вполне мощная техника наследования форм. Кроме того, направленность на GUI-дизайнер влияет на архитектуру визуальной библиотеки, в результате, хоть в своём программном коде можно делать абсолютно всё (дизайнерство никак не ограничивает в коде), но работать с GUI в коде неудобно, громоздко (если с нуля что-то создавать).
Delphi повлиял на Net, там тоже любят дизайнеров. А вот в жабе как-то дизайнеры особо не востребованы. Там научились программировать, хотя джава как язык не фонтан для этого. Для расположения контролов используют выравниватели — layout manager.
Вот очень популярное решение MigLayout (в инете куча статей про него). Сейчас его пытаются портировать на всякие разные платформы.
Кстати, в нашем скриптовом язычке тоже по таким мотивам программируется GUI.
PSV>>Или вот попался пример на WPF (я в нём не разбираюсь). Здесь TextBox будет виден только тогда, когда включён CheckBox (насколько приятно в таком XML ковыряться, я не в курсе, лично мне не очень): PSV>>
PSV>><Window x:Class="ParaPlan.Windows.Window1"
PSV>> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
PSV>> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
PSV>> Title="Window1" Height="300" Width="300"
PSV>> xmlns:converters="clr-namespace:ParaPlan.Converters">
PSV>> <StackPanel Orientation="Vertical">
PSV>> <StackPanel.Resources>
PSV>> <converters:BooleanToHiddenVisibility x:Key="boolToVis"/>
PSV>> </StackPanel.Resources>
PSV>> <CheckBox Content="Check to show text box below me" Name="checkViewTextBox"/>
PSV>> <TextBox Text="only seen when above checkbox is checked"
PSV>> Visibility="{Binding Path=IsChecked, ElementName=checkViewTextBox, Converter={StaticResource boolToVis}}"/>
PSV>> </StackPanel>
PSV>></Window>
PSV>>
_>Вот это уже ближе к тому, что мне хотелось бы. Но в таком дико уродливом виде естественно не имеет смысла. И насколько я вижу тут все проблемы от того, что ставилось требование обязательной декларативности. Кстати, тут вот параллельно проблемы sql обсуждали — тоже самое опять же. Похоже для некоторых разработчиков декларативность является чем-то священным, не смотря на то что в дальнейшем она приводит к ужасающему коду.
Не знаю на счёт Net-а, но для Delphi и Java я насмотрелся на кучу всяких декларативных велосипедных описаний для GUI, включая и на основе XML (таких, имхо, и больше всего). XML якобы промстандарт, есть универсальные инструменты, в том числе и IDE с ним работают (включая и спецсредства под конкретный язык, как этот XAML), также есть способствие к кодогенерации. В WPF с Сервелатом вроде можно и в коде работать, не только с XML, но я смотрю, что многие внутри XML и работают, ибо в C# ещё больше неудобств (хотя я не в курсе, вполне возможно, что часть функционала только в XML и возможна).
Вот я давал пример с JavaFX. Сейчас, в принципе, сделали по уму: теперь это часть самой джавы, т.е. обычные жабьи классы со своим API, и есть из коробки вариант работы и через XML, можешь ваять отдельно разметку, стили и т.д. А хочешь, бери любой язык под JVM — кложуру, груви, питон и т.д. и вперёд. Хочешь делай свой DSL, какой тебе нужно. Можно взять тот скриптовый язык, на котором я приводил пример. Кстати, он как DSL вполне хорош, но лично мне не всё нравится в синтаксисе. Говорят, что он похож на флэш или Flex какой-то (я в них не шарю).
_>Да, я посмотрел — это как раз ближе к тому, что мне интересно для нативных предложений, но что я не стал бы применять в вебе (это я про первый пример оттуда). В современной веб разработке обычно стараются уйти от каких либо намёков на код внутри html. А тут некие привязки и т.п. В то же время для приложения с нативным интерфесом это возможно было бы удобно, причём возможно даже можно было совместить в единое целое view и view-model.
_>А разница на мой взгляд в том, что под дизайном в случае сайта и в случае приложения с нативным интерфейсом частенько подразумеваюся достаточно различающиеся вещи.
Ну, прежде всего, нужно ориентироваться на конкретные задачи, конкретные потребности. А в таком, глобальном, масштабе я с тобой не соглашусь. Вот тот же HTMLLayout специально создавался с целью позволить разделить дизайнерчество от программирования, ну кроме того, чтобы дать возможность делать любой интерфейс и как-то упростить программирование. По своему опыту могу сказать, что лучше всегда стремиться к простому, гибкому, и если есть обоснованная (!) возможность что-то разделить, отвязать — лучше так и сделать. Я и в программном коде привык писать попроще, лучше накидать с десяток простых строк, чем замутить одну, в которой потом через несколько лет сам же не разберёшься. Сейчас я могу что-то не увидеть, не догнать, но потом может так вжарить петух, что будешь браться за голову и гадать, как имеющееся месиво кода переделать.
Кстати, HTML и в десктоп-GUI весьма популярен. Вот ещё один известный "равнятель" для Java: TableLayout, разметка в HTML-стиле. А вот здесь товарищ попытался его совместить с выше приведенным MigLayout (мне не понравилось то, что есть переплетение разметки со стилями, т.е. с визуальным оформлением).
А я, сам для себя, пришёл к такому выводу. Обязательно нужно:
декларативное описание GUI. В рамках вэба стандарт является HTML, он же повлиял и на десктоп. Его недостаток в том, что он труден для восприятия и для прямой работы с ним. Также он затрудняет задачи локализации (разные варианты языков), если убрать из него содержательный текст, останутся только одни тэги, причём в этом случае они неудобны, ведь HTML — это язык для разметки элементов внутри текстового документа (для чего он и предназначался), а теперь текста и нет, сплошные неудобные угловые скобки. Но он стандарт, поэтому востребован.
Второй вариант, это DSL по мотивам JavaFX-скрипта, пример которого я приводил раньше. Он оперирует не текстом, а GUI-элементами: сценами и объектами внутри них. В принципе, тут даже и спецы-дизайнеры также смогут работать, ибо, как я понимаю, это уже тоже некий типовой промстандарт. Конкретно JavaFX-скрипт позволяет ещё и включать сразу в себя и программный код, внутри описаний, но этот вопрос решаем (в этом и плюс тоже, тут и дизайнерам может даже что-то пригодиться, но как-то это нужно ограничить, но не ликвидировать полностью).
Имхо, сейчас эти два формата промышленно рулят. К ним (лучше всё-таки отдельно) нужно декларативное указание биндинга, реактивности, но уже удобное в рамках языка программирования (или внешний DSL, если язык программирования такой ...).
Да, и нужны декларации для визуального оформления по мотивам CSS, отдельные от разметки. Это есть и в HTML, и в JavaFX (тут тоже не помешали бы какие-то небольшие вычисления, удобные для дизайнеров).
А этот микрософтский XAML — в какой-то степени JavaFX-скрипт, но в XML-формате. Спецы по нему вроде только в рамках около WPF. Имхо, для ручной работы неприятен, несмотря на чудеса от IDE. Такой XML, как и в JavaFX, имхо, лучше применять в рамках кодогенерации, в т.ч. и при работе GUI-дизайнеров, для чего, в первую очередь, их и придумывают. Я же пытаюсь нащупать способ для простой жизни, без дизайнеров.
Нужно и удобное прямое алгоритмическое программирование GUI. Какое бы не было крутое декларативное описание, но всех потребностей оно никогда не покроет. Здесь какой-нибудь miglayout очень кстати (соответственно и декларативный DSL должен иметь как бы прямую связь с API языка программирования, т.е. в DSL задаются те же элементы, что и в этом miglayout).
Неплохой помощник тот язык, который может удобно (!) оперировать и некоторыми элементами из DSL, по мотивам JavaScript при работе с XML/HTML-тэгами (а также, например, Scala, и в Nemerle что-то есть для работы с XML).
И в идеале, неплохо, если язык/платформа позволяют делать нужные мета-вычесления при компиляции, если в этом есть необходимость. И очень хорошо, если есть возможность для true-реактивности — сразу видеть свои результаты не отходя от кассы.
S>DSL для построения парсеров позволил бы значительно сократить время разработки и избежать приседаний с внезапным переходом с CSV на TDV после запуска системы в эксплуатацию в РФ, где десятичной точкой неожиданно является запятая.
А если есть биболиотеки тот же CSV уже читающий, то и DSL'ей не надо
На прошлой работе надо было импортировать Excel (не CSV, а .xls). Питон + xlrd дают что-то такое:
book = xlrd.open(path)
for sheet in book:
for row in sheet:
for column in row:
...
Цепочка импорта чуток удлинняется, в качестве разделителя задаются tab. Формально это не csv, но главное это импорт, а на форматы забили. Бизнес не будет проверять CSV или нет, он будет проверять проходил ли сам импорт. Обычно дает набор файлов.
Ты только что говорил, что студенты на выходе не умеют программировать и тут же выдаёшь в качетсве хорошей ссылки материал, который эти студенты по твоим же словам не в состоянии осилить.
Откуда?
Но непонятная подача материалами еще не значит, что его в принципе невозможно подавать проще.
