Здравствуйте, VladD2, Вы писали:
VD>Можно даже ДСЛ пределать, но важно другое. VD>Важно то, что в идиале из пдобных "скриптов" вообще не нужно вывзать никакие екзешники. Ведь расширение будет не за счет утилит, а за счет компонетнов, классов и т.п.
Ты говоришь о модификации синтаксиса с помощью макросов?
Эта идея выглядит очень здраво, только надо придумать в какую сторону его модифицировать и предоставить маленький набор абстракций, которые могут комбинироваться друг с другом огромным числом способов (очень грубо говоря как pipe'ы).
Мне вот почему то приходят на ум list comprehensions Haskell'я — т.е. такая же компактность записи и мощь.
Уверен, что нечто подобное обязано появиться, типа LINQ, только более универсальное.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>>>Буквой i. Можно. K>>Ну что ж. Я тому несчастному, который попытается использовать (а таких нет, т.к. продукт закрытый) эту iDE, не позавидовал бы, т.к. меньшая продуктивность достижима только в блокноте.
TBG>Но большая, чем в блокноте, что не может не радовать.
Что же, любой редактор текста, сложнее блокнота, будем называть iDE?
Здравствуйте, PhantomIvan, Вы писали:
PI>спасибо, но возникает вопрос: PI>а почему ты не использовал Visual Studio и его SDK ?
Во-первых, мне сказали, я пишу.
Во-вторых, тут несколько иная задача. Есть у нас своя платформа для автоматизации бизнес-процессов, что-то вроде 1C, только быстрее . Но есть в платформе один недостаток — писать схемы (конкретные решения для конкретных предприятий) можем только мы. А вот как оказалось, делать только штучные эксклюзивные решения невыгодно экономически. Потому логично работать по трём направлениям:
1) массово продавать типовые решения. Пока работаем над этим, но пока есть определённые трудности;
2) продавать платформу и некий SDK для неё сторонним разработчикам, которые пишут решения для предприятий;
3) объединить подходы 1 и 2, продавать типовые решения с SDK, при этом саппортом занимаются IT-отделы предприятий.
Собственно, выглядеть это должно примерно так. Когда в систему заходит бухгалтер, он выбирает схему "Финансы бла-бла-бла", вводит логин, пароль и работает в качестве бухгалтера. Если же в систему входит программист Василий Пупкин и выбирает схему "SDK", то он попадает в среду, где он может модифицировать схемы.
На начальном этапе не планируется писать крутого IDE с поддержкой C#. Пока просто планируется объединить набор утилит и мастеров, которые осовбождали бы программиста от написания большой части кода вручную, чтобы потом в VS пришлось работать как можно меньше. А затем, возможно, будет полноценная поддержка C#. Причём в понятие "полноценная поддержка" не будет входить, например, рефакторинг, т.к. при помощи мастеров планируется довести всё до такого состояния, чтобы код, написанный вручную, был чрезвычайно простым для сопровождения.
Ну, нам ещё нужен был текстовый редактор. Причём ни один из существующих не удовлетворял потребностям. А нужен этот тектовый редактор для редакторования сформированных отчётов (не путать с редактором отчётов в SDK), для использования на некоторых формочках и т.д. Нужно, чтобы это было ближе к HTML, чтобы можно было свободно внедрять контролы в текст и текст в контролы, чтобы были таблицы, графики и т.д. Тот текстовый редактор, что на скриншоте, это в принципе поддерживает, только в нашем "IDE" была задействована часть его функциональности.
Текстовый редактор я прикручу к гриду. А то я в своё время на столько граблей понаступал, когда в ячейки внедрял TextBox'ы. А тут и функциональности побольше, и встроить это будет проще. Кстати, у грида тоже не есть велосипед, просто в своё время мы не нашли нормальных (в смысле, выглядят навороченно, куча понтов, а метода чтобы сделать какую-нибудь штуковину, в помине нет) да и кроме того, у нас скоро повсюду будет свой Binding .
Здравствуйте, EvilChild, Вы писали:
EC>Мне вот почему то приходят на ум list comprehensions Haskell'я — т.е. такая же компактность записи и мощь.
Так в Немерле (и кстати в Скале тоже вроде того (for-comprehensions)) они есть (только не ленивые, хотя я может быть поговорю с авторами по поводу ленивости): здесь.
Sinclair wrote: > Здравствуйте, raskin, Вы писали: > R>На 1000 точек руками будут вбивать мои враги. > Ексель позволяет это сделать даже без изучения макросов. Позор
Вбить 1000 точек руками позволяет без проблем.
> программисту, неспособному освоить настолько оптимизированный под > пользователя инструмент.
Я представляю один способ это разумно сделать — растяжением выделения за
угол. Как бы не два раза применённое (это я, вероятно, торможу). Но
заменить быстро границы построения графика я уже не сумею. Я не понимаю
логики этого GUI, поэтому просто не уверен, что искать в справке.
Поэтому так и не собрался — так как знаю несколько способов сделать это
легко другими средствами.
> R>Автоматизировать — не хватит мне знания Excel на то, чтобы результат не > R>требовал лишних телодвижений. > О да, конечно. Куда проще освоить новый язык программирования/разметки, > чем включить запись макроса в екселе и посмотреть, что именно ты делаешь > ручками.
Чтобы просто говорить "функция такая-то, отсюда дотуда через столько"
мне придётся, боюсь, таки вспомнить Visual Basic. Не хочется. Я лучше на
J, он мне приятнее.
>>> Так что не выдумывай. > R>У меня RAM 768MB. Эффект мгновенного запуска Excel я не наблюдаю. > Не выдумывай. Ексель страшным образом оптимизирован по потреблению > памяти. Он прекрасно работал у нас и на 256MB.
Ну не знаю, больше секунды он грузится. Значит, действительно, дело в
диске. Дело на ноутбуке.
> Только что запустил его на перезагруженной машине (так что кэшироваться > он не мог) — меньше 1 секунды. Workset — 38MB, из них ~21 shareable.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Так в Немерле (и кстати в Скале тоже вроде того (for-comprehensions)) они есть (только не ленивые, хотя я может быть поговорю с авторами по поводу ленивости): АХ>здесь.
Здесь фишка не в их наличии, а в том, чтобы с таким синтаксисом (в плане компактности и мощи) решать более общие задачи.
И чтобы это было просто и естественно как пайпы.
PI>>и вообще, подумай с чем ты споришь: я тебе говорю, мне нужно это PI>>а ты мне говоришь, что мене это не нужно... может мне лучше знать, что мне нужно?
TBG>Хорошо. Читаем историю (цитата ниже). Я так понимаю, Вы спрашивали человека, есть ли это у него? Я ответил (да, тут я весьма обобщил), что для TeX компайл не нужен в рантайме как таковой. После чего Вы привели в пример Вашу ситуацию. Тогда я справедливо заметил, что и F5 нажать несложно.. Но тут тоже проблемы..
я и говорю, что ф5 мне нажать сложно
(ну, мне ещё нужно на самом деле подключить тех к своей проге...)
неважно короче.. если ты считаешь, что "справедливо заметил, что компилить несложно"... что ж, могу порадоваться только твоему умению видеть за других и дальше других
TBG>Возможно. Раз уж Вы знаток ТеХ (я только новичок), не посоветуете, как можно удобно и быстро набирать в нем химические формулы?
я не знаток, и хим. формул никогда не вводил в него
советую произвести поиск по 2 направлениям:
— собственно химические стили/пакеты для тех
— и поддержку математических коммутативных диаграмм в техе
и 3 способами:
— TUG (tex users group) — там можно спросить
— зайти на arxive.org и посмотреть, как там люди коммутативные диаграммы делают (этого должно быть навалом в теории категорий, или ядрёной теории групп)
— гугл
кажется я давным-давно какие-то расширения теха видел для хим. формул — но уже не помню что и где
если найдешь — напиши, что там лучше всего для них
если нет — тоже напиши, попытаюсь помочь с поиском
TBG>Имеется сервак с выходом в интернет через проксю на другой машине. Прокся активна с часу до пяти. Сервак в заданное время проверяет наличие канала и обновляет список с удаленных серверов в нете, далее по обновленному списку начинает закачивать файлы и складывать их в определенное место на сети. В любой неопределенный момент сеть может быть недоступна. Поэтому стоит подождать и выкладывать. И стирать локально по завершению аплоада.
а это вообще программистская задача, а не административная
TBG>Ну или оцените трудоемкость данной задачи (чел/час).
Здравствуйте, Sinclair, Вы писали:
S>Почему в 21 веке мы до сих пор вынуждены писать совершенно дурацкие скрипты с проверкой error_level после каждого вызова и корявыми goto вместо обработки исключений? Почему единственным механизмом взаимодействия процессов, управляемым из шелла, является piping stdin/stdout?
Кстати, о том, на что способна работа с stdin/stdout можно посмотреть, например, здесь:
Или, к примеру, редактор TextMate. Его способности основаны на том, что для обработки фрагментов текстов запускаются внешние Ruby-скрипты. Как продемонстрировано, например, в Objective-C Part 2 (mov файл на 11Mb).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, EvilChild, Вы писали:
EC>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>Так в Немерле (и кстати в Скале тоже вроде того (for-comprehensions)) они есть (только не ленивые, хотя я может быть поговорю с авторами по поводу ленивости): АХ>>здесь.
EC>Здесь фишка не в их наличии, а в том, чтобы с таким синтаксисом (в плане компактности и мощи) решать более общие задачи. EC>И чтобы это было просто и естественно как пайпы.
Приведи пример тогда. Пример pipeline-обработки (кстати, без всяких comprehensions) был здесь
PI>>чувак, ты гонишь
TBG>Не нервничайте так. И перечитайте еще раз что вы ниже написали.
а я не нервничаю — я просто говорю, что ты гонишь
PI>>это всё была ирония по поводу того, что местами ты говоришь банальности PI>>тут нет ни одного человека, который бы заведомо не знал о чём ты в таких местах говоришь
TBG>Это прекрасно. Повтороенье — мать учения. Если не согласны с моей репликой про расширяемость языков — опровергните. Если же согласны и нечего сказать, то к чему Ваша первая фраза?
с репликой полностью согласен
и все согласны
первая фраза ("чувак, гонишь") была к тому, что советую прежде чем что-то писать, тщательно обдумывать
ну, например, потому что
немерле обладает теми возможностями, которыми наделяет её тот, кто этим немерле пользуется
Справедливо для любого языка программирования. Речь пойдет лишь о степени расширяемости. То есть немерле, лисп могут расширить свой синтаксис. Многие мейнстримовые — нет, но они расширяют свою функциональность за счет библиотек.
вот это содержит лишь 2 мысли:
1) си-подобные языки расширяются библиотечно
2) лисп, немерле ещё и макросным образом
ну дык это в тысячный раз здесь повторяется, и ценности высказывание не представляет (как по мне)
E>>>Так что LaTeX, после того, как его освоишь, оказывается очень дешевым и сердитым таким решением.
PI>>ну, я пробовал его для документирования программ... и не увидил особых преимуществ перед тем же Word-ом даже
E>Я думаю, что вам не доводилось писать документацию вроде Grokking_Nemerle да еще с несколькими соавтарами.
ага, редко от меня требовалось документацию писать
всё требовали функциональность, и побыстрей
но для документации я бы выбрал мсдн, и интеграцию в мсдн
а если чисто на вебе, и несколько авторов, то наверное, вики-стиль (и движок википедии, само собой)
PI>>да и вообще, я к документированию кода отношусь сдержанно — на сишарпе например, код самодокументируемый (даже без комментов)
E>Документация к программным системам и задокументированный код -- это не одно и тоже. Даже если брать требования ГОСТ-а к документации, то там было столько разного (руководство системного программиста, руководство пользователя (не помню точно как называлось) и пр.), сколько ни из какого кода не достанешь.
та ну, про госты не вспоминай, лучше сразу за царя Гороха
с выделенным согласен, но считаю, код должен быть максимально самодокументируемым, тем или иным способом
код _к_ программной системе в идеале — это всего лишь извлечение некоторой выборки доков из полного комплекта "задокументированного" кода
.
Похоже, но всё равно уступает в понятности shell'у. Я в общем сразу сказал, что придумать адекватные абстракции очень сложно, у меня пока идей нет.
АХ>Правда, конечно это только снаружи конвейер. Внутри же каждый этап выполняется последовательно. Но это уже скорее вопрос реализации.
Это момент принципиальный — внутри всё обязано быть лениво иначе тормоза.
АХ>Да, кстати единицей передачи по конвейеру в случае bash насколько я понимаю являются только строки, так?
Ага. Было бы здорово, если бы они были всего-лишь частным случаем. Мне кажется в функциональных языках абстракций подходящих придумали достаточно, вопрос придания им вида пригодного для решения таких задач.
. EC>Реально без всяких подколок интересно как это можно так же быстро и компактно сделать иначе. EC>Если нужны пояснения как это работает — без проблем.
ок, можно для тех, кто не в танке, объяснить что вот это
PI>>наверно, ещё некоторая дань юниксоидам, типа как они привыкли
TBG>Кто-то тут недавно говорил, что если есть то-то и то-то, значит, кому-то было нужно.
ну да, на конференции недавно был пост по этому интепретёру, кому то значит, понадобилось
TBG> И не просто так поразвлекатсья.
лично я развлекался с ним минут 5... зачем он, кроме развлечения нужен, не знаю всё же
просто если кто-то злобный спрашивает "а немерле — компилятор, а не интерпретатор, значит сакс"
то я ему говорю "ха, вон интерпретёр лежит — бери и юзай"
типа proof-of-concept
но чтобы его кто-то пользовал как основной инструмент.. гм... это типа командной строки и батников
чето маленькое можно попробовать из команд лайн, а если что побольше — нужно уже в батник пихать (в вижал студию идти и компилить)
PI>>спасибо, но возникает вопрос: PI>>а почему ты не использовал Visual Studio и его SDK ?
K>Во-первых, мне сказали, я пишу.
K>Во-вторых, тут несколько иная задача.
в принципе понятно, но есть стойкое ощущение, что это всё вы повторяете то, что есть в вижал студии
(особенно в DSL tools этих, так называемых)
вместо того, чтобы модифицировать то что есть
скажем так, если бы код вижал студии был бы полностью доступен
ты бы склонился к тому, чтобы взять его и модифицировать,
нежели писать текстовые редактор, редактор диаграмм, и пр. с нуля?
