Здравствуйте, VladD2, Вы писали:
VD>Насколько я помню исходно ставлися тезис что шел-скрипт — это ДСЛ который чем-то лучше чем универсальный язык. Вместо доказательства этой позиции тема сошла в демогагическое обсуждение того, то наличие готовых утилит оправдывает убогость ЯП и его среды.
А так и есть, возьмем некий заголовок:
#!/bin/interpreter
Теперь линуховый мир пополнился и интерпретатором Nemerlish (nemish).
VD>Полноценный язык который (компилируемый, что немаловажно), возможность использования отличной IDE, отладчика, моря библиотек, качественной документации.
Зачем тогда проекту Nemerle вдруг понадобился этот nemish?
Здравствуйте, konsoletyper, Вы писали:
K>Когда-то, когда из меня так и пёр юношеский максимализм, я наслушался "крутых хакеров", что Юникс — это круто. Тогда подыскал себе дисков с Linux'ом и FreeBSD. Специально в течение полугода насиловал себя изучением shell, ощущая при этом свою офигительную крутизну, плевался на Windows и VS, что, мол, эта фигня — для ламеров. Но потом просто устроился на работу и там просто увидел, что иногда нужно что-то сделать
Заметно. Уж Вы извините, но эта история у Вас с самого начала ваших сообщений написана. Можно было бы и не повествовать.
K>быстрее и удобнее и просто сэкономить своё время на что-то более важное. Уж так устроен человек — в детстве он не обременён заботами, у него куча времени; когда же он взрослеет, у него появляеются обязанности и он начинает ценить своё время, которого катастрофически не хватает.
Как раз об этом и речь. Если человеку быстрее и проще сделать на shell — зачем ему разворачивать это дело на Java? На C#? У всего своя ниша. И не стоит что-то одно пытаться применить ко всему. Например, станком с ЧПУ клеить марки на поздравительные письма.
K>Я не спорю, что кому, в силу его специфических задач, пользоваться shell'ом удобнее. Но мне, как рядовому пользователю, супервозможности шелла нафиг не нужны, мне нужно что-то попроще и попродуктивнее, что не нужно было бы каждый раз переучивать заново.
Вас кто-то заставляет им пользоваться? Пользуйтесь тем, что для вас продуктивнее. Все остальные будут пользоваться тем, что для них продуктивнее. Только не надо удивляться почему это то, что продуктивнее для вас, менее продуктивно для других.
Здравствуйте, VladD2, Вы писали:
TBG>>А никто не хочет пописать интеграцию на готовой интеграции MonoDevelop? Сам не смотрел, но учитал в features'ах строчку "Nemerle Project Support". VD>Ты бы сначало спросил можно ли ее вообще использовать.
Как раз это и спрашиваю.
VD>На сегодня она вообще не работает. Я когда начинал Интеграцию ддя студии использовал как раз движок созданный для MonoDevelop. Так вот он практически не работал. Там все было на соплях, да и назвать "это" словом "было" тоже натяжка. Там были зачатки комплита. Которые работали в 1 случае из 10. Плюс кривая подсветка реализованная на шарпе в самом проекте MonoDevelop. VD>Учитывая что даже сейчас полноценно использовать Интеграцию для собственной разработки практически невозможно, то понятно, что говорить об использовании MonoDevelop вообще не серьезно.
Здравствуйте, IT, Вы писали:
IT>Всё как раз с точностью до наоборот. Одна из основных проблем с которой приходится сталкиваться при написании интеграции — это отсутствие навигации по коду. Для того, чтобы понять как работает тот или иной класс или метод нужно перейти к его объявлению и посмотреть как оно там всё устроено. При нормально работающей "фенечке" — это одно нажатие кнопки.
Как раз в плане навигации — я за встроенную таковую в IDE (можно и vim доточить, но не хочется, потому что есть готовое).
Здравствуйте, konsoletyper, Вы писали:
K>Ни рефакторинга, ни навигации по коду, ни тем более autocomplet'а нет. Зато есть текстовый редактор и диаграммки. Можно это считать IDE с буквой I?
Здравствуйте, VladD2, Вы писали:
TBG>>Подчеркнем слово лично? VD>Да, согласен, "лично" здесь было куда лучше чем "у тебя".
Ну хоть с этим разобрались, что у каждого свое "лично". +
TBG>>Гугль тоже помогает добыть нужную информацию.. VD>Молодец. Вставил весоме слово. И хотя к делу оно не относится, но типа поддержал беседу.
Всегда надо уметь поддержать беседу. Особенно про источники информации, среди которых нет единственного.
Курилка wrote: > S>Так вот, запросто может оказаться, что через X лет управление ОС будет > осуществляться на строготипизированном скрипте, а современные > шелл-скрипты будут вызывать веселый смех, как сейчас забавляет процедура > загрузки электроники-60 с вводом машкодов. > А есть какие-нибудь реальные наработки в этом направлении?
Monad Shell от MS.
Хотя как-то пока оно выглядит не очень. Обычные shell-скрипты не хуже.
Здравствуйте, Курилка, Вы писали: К>А есть какие-нибудь реальные наработки в этом направлении?
Я, если честно, не в курсе.
Но знаю, куда надо смотреть: фундаментальная проблема скриптов в том, что предметная область, в которой они оперируют, очень убога. Там, грубо говоря, нечего типизировать. Максимум, чего можно добиться — это понимание бинарных/текстовых потоков.
Поэтому результат можно ожидать там, где сама ОС работает с более сложными объектами. Некоторым приближением можно считать WMI — там типизация хоть и достаточно слабая, но есть.
В осях на основе Оберона ситуация с программированием шелла должна быть существенно лучше. Также можно ожидать некоторого прогресса в Java OS.
Как только мы получим вменяемую объектную модель для операционной системы, сразу появляется искушение ввести прямое управление объектами этой модели вместо опосредованного доступа через командную строку. Этакий шелл, в котором скрипт как бы вовсе и не скрипт, а эдакий code fragment, который тут же компиляется во что-то типа LCG-метода дотнета и исполняется. На мой взгляд, это было бы вполне круто. В частности, потому, что можно было бы делать крайне интересные решения в виде, к примеру, обработчиков событий. Типа вот так вот пишешь:
И всё. Работает совершенно симметрично — что через command line, что через API.
Кстати, для дотнета это вообще крайне грамотно. В том смысле, что можно написать и обратно-совместимый по синтаксису с cmd.exe язык, компилируемый в тот же байт-код; можно программировать шелл прямо на C#; можно изобрести язык, который будет менее многословен на типичных шелл-задачах, чем шарп, но более строг и выразителен, чем шелл.
И все эти языки будут совершенно чудесным образом интероперировать между собой. И не будет принципиальной разницы, на чем написан обработчик того или иного события.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Turtle.BAZON.Group, Вы писали: TBG>Если проект со всеми вытекающими, то тогда да. Но если нужно подредактировать файлик (настроек к примеру), зачем мне для этого использовать полновесную IDE?
Давайте отвлечемся от частных деталей. Потому как они завсегда порождают встречный вопрос: а если не нужно?
Есть определенные виды активностей. Эти активности продиктованы жизненными потребностями. Для автоматизации этих активностей придумываются практики, с использованием тех или иных инструментов. И рассматривать инструменты вне практик и вне активностей — бессмысленно. Точно так же, как спрашивать "зачем мне использовать полновесную IDE для циклевки паркета?".
Так вот, есть такая активность "разработка приложений". Как и для всякой другой активности, практика для нее тем эффективнее, чем лучше соответствующий инструменарий. С этой точки зрения, IDE — это такой специализированный станок. Который, предположительно, должен включать в себя как можно больше действий, совершаемых в рамках процесса разработки софта. В итоге, "редактирование файлика настроек" может сильно различаться, в зависимости от того, в рамках чего оно делается. Если мы правим web.config для приложения, которое мы сейчас разрабатываем, то
во-первых, совершенно нелогично выходить ради этого из нашей IDE
во-вторых, IDE знает неизмеримо больше, чем любой самый умный текстовый редактор, о смысле этого файлика. Особенно если этот файлик вовсе не конфигурирует какое-то реальное приложение, а лишь описывает те настройки, которые будут применены к будущему приложению при его развертке. Улавливаете разницу? Умная IDE может не только следить за балансом скобок в конфиге, а и смотреть, какие классы ConfigurationSection будут доступны для будущего приложения еще до его компиляции, не говоря уже о деплойменте.
С другой стороны, "редактирование файлика настроек" может выполнять и админ. У которого, в силу его обязанностей, никакой IDE быть не должно. Потому, что development не для него. Для него родная среда — это "IAE", или некая Контрольная Панель. С этой точки зрения, опять же, совершенно непонятно, почему админ вынужден вместо нормальной контрольной панели ковыряться в файлике настроек допотопным текстовым редактором. Да, я заранее соглашусь, что если СуперМегаКонтрольнаяПанель упала и не в состоянии обеспечить настройку софта в подведомственном домене, старый добрый текстовый редактор будет неплохим подспорьем. Но в нормальных случаях любой админ предпочтет удобный в конфигурировании тул, отвечающий его потребностям. И с возможностью массового администрирования целого домена, с логами и откатами. И для него не стоит вопрос "зачем запускать тяжеловесную CP, когда можно поправить файлик текстовым редактором". У него эта CP — основное рабочее место. То же самое, как курьера спросить "зачем садиться в тяжеловесную машину, чтоб проехать 500м, когда можно пешком дойти." Да затем, что предлагается ему как раз вылезти из машины, где он практически живет, пойти пешком, а потом еще переться назад, чтобы обратно сесть в машину — следующая точка расположена через три километра.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>можно изобрести язык, который будет менее многословен на типичных шелл-задачах, чем шарп, но более строг и выразителен, чем шелл.
Nemerle?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Давайте отвлечемся от частных деталей. Потому как они завсегда порождают встречный вопрос: а если не нужно?
Так тут все время к частностям и переходят. Я как раз и хочу сказать, частности, как и крайности, весьма забавно смотрятся.
S>Так вот, есть такая активность "разработка приложений". Как и для всякой другой активности, практика для нее тем эффективнее, чем лучше соответствующий инструменарий. С этой точки зрения, IDE — это такой специализированный станок. Который, предположительно, должен включать в себя как можно больше действий, совершаемых в рамках процесса разработки софта. В итоге, "редактирование файлика настроек" может сильно
О чем, собственно говоря, речь и шла.
S>различаться, в зависимости от того, в рамках чего оно делается. Если мы правим web.config для приложения, которое мы сейчас разрабатываем, то во-первых, совершенно нелогично выходить ради этого из нашей IDE
Или при деплойменте когда необходимо поправить количество соединений, которые держит пул базы данных с 4 на 8, к примеру, то нелогично ставить IDE. Рассуждам про мягкое с теплым.
[часть поскипана] S> СуперМегаКонтрольнаяПанель упала и не в состоянии обеспечить настройку софта в подведомственном домене, старый добрый текстовый редактор будет неплохим подспорьем. Но в нормальных случаях любой админ предпочтет удобный в конфигурировании тул, отвечающий его потребностям. И с возможностью массового администрирования целого домена, с логами и откатами. И для него не стоит вопрос "зачем запускать тяжеловесную CP,
[часть поскипана]
Администратор он на то и администратор, что настраивает приложение один раз. Или перенастраивает раз в год (или по потребности). В общем, не очень часто. Мало кто согласится при таких условиях тратить время на разработку таокого ПО как СуперМегаКонтрольПанель (в которой заблудиться тоже можно будет). Да и администратор — это не пользователь, который не знает какую галочку тыкнуть (хотя такое часто встречается), а человек вдумчивый и ответственный..
Да и еще при деплойменте это на *nix сервак, где графику отродясь не держат, придется реализовывать через web. В общем, пути разные есть. Только есть еще и вопрос о смысле всего этого. Ведь гораздно проще раз в год поправить текстовый файлик.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sinclair, Вы писали:
S>>можно изобрести язык, который будет менее многословен на типичных шелл-задачах, чем шарп, но более строг и выразителен, чем шелл. WH>Nemerle?
Maybe. Но чтобы доказать его жизнеспособность в качестве шелла, нужно как минимум изобрести модель окружения, в котором он будет работать. Ну и продумать его работоспособность в случае "однострочных" команд. Накладные расходы на явное задание контекста в шарпе, к примеру, делают его малоприменимым для консоли. Кого угодно запарит каждый раз набирать
using System.Environment;
namespace Temp
{
public static class MainClass
{
public static int Main(string[] args)
{
Process.Start("calc.exe");
}
}
}
По сравнению с просто "calc.exe" — это чудовищно. Про немерле ничего не знаю.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Или при деплойменте когда необходимо поправить количество соединений, которые держит пул базы данных с 4 на 8, к примеру, то нелогично ставить IDE. Рассуждам про мягкое с теплым.
Еще раз напомню, что мы говорим об использовании IDE в разработке, а не при развертывании продукта на предприятии. Прекратите передергивать.
TBG>Администратор он на то и администратор, что настраивает приложение один раз. Или перенастраивает раз в год (или по потребности).
Ты можешь заранее сказать, насколько часто возникают административные потребности? Для сверхредкого администрирования рулит ГУЙ, потому что вспомнить, какой файлик, и как поредактировать — это мука. Куда проще пользоваться user-friendly панелькой, которая помогает. Для сверхчастого администрирования (например, если ты админишь хостинг), текстовые редакторы тоже сосут. Потому что это мука — всякий раз решать типичную задачу вроде "накатить линукс, развернуть VZ, раскатать VE, раскатать Plesk и т.п". Куда удобнее пользоваться CP, которая не требует SSH логина в remote host и выхода в текстовый редактор для правки DNS-базы. Сделал себе Create Subdomain в CP и горя нет.
TBG>В общем, не очень часто. Мало кто согласится при таких условиях тратить время на разработку таокого ПО как СуперМегаКонтрольПанель (в которой заблудиться тоже можно будет). Да и администратор — это не пользователь, который не знает какую галочку тыкнуть (хотя такое часто встречается), а человек вдумчивый и ответственный.. TBG>Да и еще при деплойменте это на *nix сервак, где графику отродясь не держат, придется реализовывать через web. В общем, пути разные есть. Только есть еще и вопрос о смысле всего этого. Ведь гораздно проще раз в год поправить текстовый файлик.
Ага. То-то я смотрю веб-панели для администрирования юниксов продаются — только шум стоит. А "людей, которые согласятся..." конечно мало. У нас в офисе они несколько комнат занимают.
Это, конечно же, от большой любви юникс-админов к консоли и текстовым редакторам.
Возвращаясь к теме: итак, в рамках какой именно активности рулят скрипты и текстовые редакторы? Администрирование и разработка софта только что встали и вышли.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, PhantomIvan, Вы писали:
PI>о, чрезвычайно интересно PI>а что в качестве технологии используется?
Технологий разных много. Во-первых, редактор диаграмм писал не я. У нас уже давно такая утилита есть, а я как раз занимаюсь IDE, вот договорился с челом, который эту утилиту писал, мы её интегрировали.
PI>рисование прямоугольников, графов с нуля? или что-то готовое есть?
Насколько я знаю, он (чел, который писал редактор диаграмм) использовал GDI+ и WinForms Вроде он написал какую-то промежуточную библиотеку для векторных редакторов вообще и для диаграмм в частоности, а затем сделал реализацию для конкретного случая. Для тулбаров используется DotNetBar. Для написания текстового редактора я написал свою библиотеку легковесных контролов.
PI>что там ещё интересного есть?
Там очень интересного со временем может быть. Например, здесь
, я выболтал кое-чего из архитектурных решений, о потенциале судите сами. Сейчас делаю парсер C#, чтобы обеспечить фолдинг, подсветку типов, навигацию и т.д. Один чел всё никак не соберётся сделать и прикрутить редактор отчётов. В целом, есть мегазадача по созданию Solution Explorer, что превратит платформу в полноценный IDE, а не просто набор разнородных утилит, но этой задачей сейчас некому заниматься.
Вкратце объясню, почему я изобрёл велосипеды с GUI. Если писать сложные контролы с подходом "тут нарисуй то, а там — это", то внутренняя структура так усложнится, что её невозможно будет сопровождать. Всякие "компромиссные" решения тоже приводят к нехорошим резальтатам. Потому я в своих контролах использую идею: "нет сложных контролов, есть совокупности простых". Например, текстовый редактор — это ScrollPanel, в который вложен TextEditPaner, в который вложен LayeredPanel со слоями TextViewPanel и CaretContainer. В свою очередь TextViewPanel состоит из VRibbonLayout, в ячейки которого вложены TextParagraph. Буквы в TextParagraph, правда, уже не являются контролами и рисуются отдельно, однако на самом деле текст стостоит из атомов, которые могут быть буквами (рисуются самим TextParagraph'ом) или контролами (рисуют сами себя). Думаю, понятно, что позиционировать контролы можно вкладывая их в различные Layout'ы, благодяря чему я даже не обращаю внимание на такую мелочь, как взаимное расположение элементов.
Свой Graphics я написал потому, что GDI+ работает медленно.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
K>>Ни рефакторинга, ни навигации по коду, ни тем более autocomplet'а нет. Зато есть текстовый редактор и диаграммки. Можно это считать IDE с буквой I?
TBG>Буквой i. Можно.
Ну что ж. Я тому несчастному, который попытается использовать (а таких нет, т.к. продукт закрытый) эту iDE, не позавидовал бы, т.к. меньшая продуктивность достижима только в блокноте.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
K>>На самом деле, никто не требует изучать по выпадающему списку, а вот пропоминание по autocompletion'у только приветствуется. Причём, порой приходится вот так "припоминать" собственный код, написанный буквально пару месяцев назад.
TBG>Мне не припоминать надо, мне напечатать надо. При этом затратив как можно меньше действий пальцами. Для этого автокомплит рулит. Ну а если свой код, который два дня назад припомнить не можете, то лучше пересмотреть политику именования переменных и классов.
Как-то день и месяц различаются, я думаю. А вообще, кто досконально помнит свой код, написанный пару месяцев назад, пусть первый броит в меня камень.
TBG>Не знаю, длиннющие набирать проще и быстрее автокомплитом (который setValueForLong типа sVFL). Мне просто долго позиционироваться курсором на нужном методе. Особенно если похожи (setValueForLongi). Но это так, для примера.
Например, есть два идентификатора: NamespaceMemberDeclarations и NamespaceMemberDeclaration. Когда я набиваю "Namesp", то курсор оказывается либо на первом, либо на втором. ИМХО, быстрее нажать <Вверх>+<Tab> или <Вниз>+<Tab>, чем вбить (возможно, с ошибкой) "aceMemberDeclarations".
Здравствуйте, Turtle.BAZON.Group, Вы писали:
K>>Ну и пользуйтесь себе vim наздоровье, если он такой удобный. Зачем столько эклектики, так много разных IDE?
TBG>А так IDE много разных потому, что в одном удобнее одно, в другом — другое.
Можно пример?
Меня просто удивляет разброс задач и IDE. Времени не так уж много, чтобы заниматься разными вещами, потому приходится становиться узким специалистом в чём-то одном. А пользоваться разными IDE непрактично.
TBG>Это все, что я говорил — в свободное время что происходит. TBG>В рабочее — Java, Eclipse, Idea, Netbeans, vim.
Опять же, прошу привести пример повседневной задачи, с которой не справляется Eclipse, но справляется vim, именно с точки зрения программиста на vim.
K>>Ну и зачем тратить своё время, когда можно в интерактивном режиме то же самое сделать раз в 5 быстрее, а потом и чайку попить, и о вечном подумать и красивое архитектурное решение найти?
TBG>Ну правильно, зачем тратить время на интерактивный дебаг, если можно все отловить до этого?
Порой не всё так просто и по логам очень трудно понять, в чём заключается ошибка. Логи хороши, когда нужно найти источник, а механизм удобнее смотреть "вживую", т.е. на интерактивной отладке. Потому нельзя ни вкоем случае отвергать ни того, ни другого.
Здравствуйте, Курилка, Вы писали:
К>Просто банально — происходит что-то в написанном тобой софте и тебе надо разобраться в ситуации (тупо глянуть в лог).
Да, и буду я час рабочего времени разбираться с тем, как мне это в шелле делать. Уж не проще ли держать для таких ситуаций специального человека? Или, например, договориться с админом на стороне клиента, чтобы он выслал лог?
Кстати, если бы на все нынешние серваки можно было бы долстучаться из GUI, то такой проблемы не возникло бы в принципе.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Курилка, Вы писали:
К>>Просто банально — происходит что-то в написанном тобой софте и тебе надо разобраться в ситуации (тупо глянуть в лог).
K>Да, и буду я час рабочего времени разбираться с тем, как мне это в шелле делать. Уж не проще ли держать для таких ситуаций специального человека? Или, например, договориться с админом на стороне клиента, чтобы он выслал лог?
K>Кстати, если бы на все нынешние серваки можно было бы долстучаться из GUI, то такой проблемы не возникло бы в принципе.
Ну нет там принципиально гуя
А логи в сотню метров особо непокидаешь почтой.
Плюс это будет гораздо медленней, чем я дойду до них и взгляну, плюс делеко не обязательно только лога достаточно или конкретного куска.
Лично нам грепа в данном случае хватает обычно, а ставить моно на солярку
Грустно.
1.2.0 alpha rev. 655
