Miguel de Icaza представил (http://tirania.org/blog/archive/2009/Mar-22.html) новый FTP-клиент BareFTP (http://bareftp.org/), имеющий поддержку FTP, FTPS, SSH и SFTF. Код BareFTP написан на C# с использованием Mono и GTK-биндинга.URL: http://tirania.org/blog/archive/2009/Mar-22.html
Новость: http://www.opennet.me/opennews/art.shtml?num=20889
и чего это он ерундой страдает... писал бы на C# сразу ядро.
и что это ты ерунду пишешь... есть языки прикладного уровня ;)
а он (да и мс тоже) в курсе? :-D
судя по его делам - да
а вот судя по твоим словам - ты нет :)
Вах! мы уже на Ты!!! :-D
тогда может и вот это прокоментируешь?
http://habrahabr.ru/blogs/programming/33014/
и вот это?
http://ru.wikipedia.org/wiki/Microsoft_Singularity
запросто, это примочки МС, а не Мигеля, а это 2 большие разницы. то что он делает - молодец, т.к. с# оч удобен и достаточно быстр именно для гуёвого использования, а ваши торомоза - ни что иное как самовнушение, ибо родителем .Net является МС :)
я не знаю сделали ли в mono аналог ngen но это тот ключ который в конечном итоге обойдёт jvm если в ней аналога не появится, при том что mono использует нативные тулкиты...то что там МС пытается сделать систему - ну пусть, их деньги их желания... пусть хоть молятся...
тока вот новость то про софтину от Мигеля ;)
другими словами писать ядра на с# всё-таки можно? :-DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
Вы же вроде говорили, что я что-то там не знаю... и где-то там не в курсе....
логично предположить, что имелось ввиду в оличае от Вас. (сомневаюсь, что Вы оффициальный представитель Мигеля на опеннет).смишно.... :-DDDDDDDDD
>то что там МС пытается сделать систему - ну пусть, их деньги их желания... пусть хоть молятся...
не только мс. (эту ссылку Вы как-то аполитично обошли http://habrahabr.ru/blogs/programming/33014/ )
>тока вот новость то про софтину от Мигеля ;)вот и я говорю... отстает парень от лидер-а(он же -ов) платформы. мелкими тулзами занялся.... может по заказу... мс-у о такую мелочь руки марать не к лицу.
Витек - ты смайлофаг такой смайлофаг. Почисти клавиатру, у тебя "d" и shift/caps-lock заедают или ты еще и блондинка?
за меня не беспокойся... за себя переживай.
клава ума не прибавит.... а моя - тем более.
Другими словами с# язык прикладного уровня (ты понимаешь что это значит?)
то что мс его на системный хочет вытащить - их дело, Мигель тут причем? где это в новости прописано?ссылки не обходил, где там Мигель засветился в этой оси? только мс, а читаем ещё раз новость - где там мс засветилось?
то что он делает - молодец, ты же тока тролишь, а как прикладной язык и платформа имхо оч удобные.
Это еще рано. Сначала надо компилятор C# переписать на C#.
А ты думаешь на чем он написан? Как там в анабиозе?
Интересно, много ему MS приплатил за пиар своего псевдо-кроссплатформенного тормозилова?
Явно больше чем получаешь ты.
>Явно больше чем получаешь ты.ИМХО не в деньгах счастье.Точнее, не только в деньгах.Они не самоцель а лишь средство в достижении других целей.Если их для этого хватает - не вижу поводов горевать.
Лет 10-15 назад быстродействие компьютеров резко выросло. В связи с чем окончательно отпала необходимость писать программы на Ассемблере. Люди посмеивались над ретроградами, которые былы готовы тратить недели, чтобы увеличить на несколько милисекунд быстродействие своего творения. Это стало ненужно т.к оптимизирующие компиляторы процедурных языков высокого уровня позволяли добиваться сравнимых результатов.
Сейчас мы подходим к новому рубежу, когда программы выросли в объеме, настоятельно требуют объектно-ориентированного подхода. Пришла пора передать под контроль компилятора управление памятью и контроль типов. Соответственно на новых языках: C#, JAVA и т.п. С этим ничего не поделаешь. Естественный ход прогресса.
извините, но вы написали бред, или вы явный провокатор флейма....
>Лет 10-15 назад быстродействие компьютеров резко выросло.с чего вы взяли?
>В связи с чем окончательно отпала необходимость писать программы на Ассемблере.с чего вы взяли?
>чтобы увеличить на несколько милисекунд быстродействие своего творения.с чего вы взяли?
>оптимизирующие компиляторыс чего вы взяли?
настоятельно требуют объектно-ориентированного подхода
с чего вы взяли?
Соответственно на новых языках: C#, JAVA
с чего вы взяли?
С этим ничего не поделаешь. Естественный ход прогресса.
с чего вы взяли?
столько провокаций в одном посту не бывает даже на лоре...
> столько провокаций в одном посту не бывает даже на лоре...Не вижу ни капли "провокационности". Я так понял - мысль такова, что раньше UNIX работал на больших компьютерах, а теперь работает в крошечных роутерах. То, что когда-то где-то было неуместно, становится в самый раз. Так же и с языками программирования и прочими штуками...
Спасибо за поддержку. Именно это я и имел ввиду.Товарищ спрашивает с чего это я взял. Собственно из личного опыта. Я профессиональный программер. Работал в крупных зарубежных компаниях. Мой код присутствует в проектах объемом до 10 млн. строк кода.
Стоимость железа упала очень значительно. Моя рабочая станция в 2000 году стоила 30тыс. баксов. Сейчас пользуюсь лаптопом за 2тыс. А вот размеры программ и требования к надежности, управляемости и безопасности растут. В месте с этим кошмарно растут затраты на разработку и сопровождение. Поэтому язык C сейчас используется для программирования микроконтроллеров (тоже личный опыт), а для общего программного обеспечения мои коллеги активно ищут язык более высокого уровня, хотя пока, конечно продолжают использовать и С и С++.
Скажите-ка, что это у вас за станция рабочая была за 30 зелёных кусков, интересно узнать... У меня в 99 году появился "современный компьютер" за 800 уёв, в который входил полный "студенческий комплект" - и в игрушки играться можно было (видяха Savage4 32MB), и дипломы печатать (принтер струйный Canon S200x). Что было в вашем за 30000 уёв?Насчёт резкого скачка 10-15 лет назад - бред. Небыло никакого скачка. Параметры компьютеров растут по закону Мура до сих пор.
И насчёт ненужности С/С++ сказки тоже другим рассказывайте. Перепишите-ка ядро линукса на вашей яве :) Да даже не ядро, даже bash перепишиет, хочу посмотреть, сколько он будет жрать памяти. То же и с вендой. Почему-то мелкомягкие не торопятся её переписывать на яве :))
> Скажите-ка, что это у вас за станция рабочая была за 30 зелёных кусков, интересно узнать...Это была рабочая станция Silicon Graphics, Inc. (SGI)под управлением IRIX. Но устарела.
В 2001 году я получил рабочую станцию SUN UltraSPARC III в очень хорошей комплектации. В т.ч. монитор 21-22 инч (не помню точно). Станция стоила 15 тыс.> И насчёт ненужности С/С++ сказки тоже другим рассказывайте. Перепишите-ка ядро линукса на вашей яве :) ...
Сначала говорили, что кино убьет театр, затем, что телевидение убьет кино и т.д. Однако все живы-здоровы. С языками программирования происходит тоже самое. Никто никого не убьет. Программер должнен беспрестрастно выбирать инструмент наиболее подходящий для конкретно поставленной задачи. Так же как это происходит в других профессиях. По моим наблюдениям, стоматолог,например, выбирает инструмент который наиболее подходит моему зубу в данный момент, а не тот, который по его мнению самый хавайный.
>По моим наблюдениям, стоматолог,например, выбирает инструмент который наиболее
>подходит моему зубу в данный момент, а не тот, который по его мнению самый
>хавайный.Зачотно сказано :).Просто среди програмеров немало придурков которые освоив свой микроскоп и налетев на задачу "забить костыль в шпалу" один фиг хватают свой любимый микроскоп и - полный вперед :).А то что он для этой задачи не заточен - да и фиг с ним дескать :)
Это экстенсивный путь развития. И он не естественнен. Пользовательских машин на порядки больше, чем элементов множества (N x M) (где N - множество аппаратных платформ, а M - множество программных платформ). Следовательно, JIT-компиляция это экстенсивное решение проблемы создания и распространения |N x M| сборок одного программного кода. Не сложно прийти к выводу, что и GC является экстенсивным решением, т.к. алгоримт выделения и освобождения памяти предопределен самим программным кодом, а GC - это лишь экстенсивный инструмент преодоления этой сложности.
Решением должно быть создание и совершентвование мета-инструментов. Отталкиваясь от Вашего упоминания Assembler'a можно прочертить интенсивный путь развития, очевидно не попавший в поле Вашего зрения: Assembler -> C -> C + макросы (как средство борьбы со сложностью) -> Vala -> ... При этом не стоит указывать на недостатки упомянутых инструментов, т.к. они приведены лишь для наглядного очерчивания "уровня" инструмента.
Пожалуй классический пример выдачи одного за другое.
Давайте по порядку
-ассемблер и сейчас актуален, хотя бы потому, что так называемые оптимизирующие компиляторы не особо то способны делать то, что делает человек на ассемблере, причина кроется не столько в непродуманности оптимизации, она неплохо работает в тех же компиляторах интеля, сколько в том, что когда вы пишете на асм под конкретный проц, то вы пишете как минимум меньше кода, чем генерирует оптимизирующий компилятор. И не только меньше, а зачастую в разы качественнее, экономя регистры и минимизируя обмен - регистры-память. Что местами создаёт разницу в разы. Но не в этом дело, дело в том что и раньше не особо на асм заморачивались, и дело просто банально в том, что писать на том же С для многих быстрее, проще и читабельнее.
-Теперь, решать проблемы "разростания" можно по раньше, жаль что вы знаете лишь С++ путь, причём зижарб и жаба этот путь значительно сужают. Проблемы разростания можно решать путём жётской модульной концепции даже на уровне не ООП языка, на уровне С, представьте себе. Можно нагородить при желании достаточно надстроек и инструментов для проекта, задействовав макропроцессоры типо m4, или даже специально написанный компилятор типо vala(только если представить что он допустим бы упрощал не ООП, а модульность), но суть одна, решать можно не только на уровне ООП, поймите это.
Кроме ООП и обычной, привычной модульности существует ещё компонентный подход. Здесь так вообще раздор, инструментов которые есть и которые можно пользовать уже сейчас в тех же открытых юниксах достаточно, в качестве примеров: XPCOM, CORBA, DBUS. Причём мы получаем значительно более обособленные куски, которые легче поддерживать отдельно, пересобирать отдельно и тд.
Это пожалуй лиш часть того что есть, а далеко не всё.
-А теперь по поводу C#,Java или значительно более мощьному C++. Дело в том, что это языки, и проблему сложности программы они решают достаточно топорным способом, выше уже сказали об этом. Гораздо правильнее решать эту проблемы на уровне архитектуры программы, а точнее если уж это большой код, то это должен быть комплекс программ. На чём их писать знаете, это как бы дело третье. Вот например чем вам haskel не угодил? Если завтра кто-нибудь напишет самый быстрый и мощьный браузер на хаскеле, вы что, будете утверждать что это ошибка?
Думаю здесь важно понять, С не умер когда появился С++, не умер когда появилась ява, не умер когда появился шарп и не помрёт похоже и завтра, почему? Потому что он язык того же уровня, потому что многие кто пишет не нём, также зная допустим С++, реально недоумевают о "слухах о скорой кончине ... сильно преувеличины". Всё потому, что квалифицированный программист на С пишет быстро, безопастно и масштабируемо. Всё потому, что все те "крутые решения" которые есть в яве, в шарпе - впринципе есть и в С. В общем если проще, то уровень языка, подобный С,паскалю, Ада, С++ - это достаточный уровень чтобы писать программы быстро, качественно и на годы вперёд.
Оно, конечно, все правильно. Но: автор осиль проверку орфографии.
Каюсь, впредь постараюсь хотя бы перечитывать написанное, дурная привычка - писать и не читать. Да и троечка по русскому тоже плохо, надо бы учебник взять в руки, всё таки родной язык:(
>отпала необходимость писать программы на Ассемблере. Люди посмеивались над ретроградами,
>которые былы готовы тратить недели, чтобы увеличить на несколько милисекундВот только в бааааааааальшом цикле лишние МИЛЛИСЕКУНДЫ легко превращаются в лишние МИНУТЫ И ЧАСЫ.Поэтому кодеки и прочие тяжелые алгоритмы по сей день пишут с асмовыми кусочками в критичных местах.И так, судя по бенчам - чисто сишная версия xvid сливает си+асм чуть ли не в разы, во всяком случае хардкорная разница в скорости видна невооруженным глазом.
А ржать над другими - ума не надо.Другое дело что писать целиком на асме весьма неоптимально с точки зрения портабельности.Вон умрет скоро i386 - и чо, переписывать всю простыню на асме с нуля?
Мигель никак не забросит идею создать двухпанельный файловый менеджер. Теперь вот решил зайти с другой стороны. :)
По скринам не заметил значительных отличий от filezilla
C# - отличный язык. И я сказал бы что Моно - полезнейшая штука, если бы оно не цеплялось под виндой и под линуксом напрямую к разным библиотекам, и программа, написанная для WinForms нормально запускалась бы под Linux в среде GTK. А пока этого нет - Жаба рулит (c) :-)
я не программист.
запустил банши и ритмбокс, и тот и тот поиграли 10 минут. Банши отьел немного меньше памяти, приятно удивило)
Если сравнивать ФТП клиент то xвалённый мозиловский сливает работой интерфейса из за использования псевдоГТК.
Бигл тормозит проц меньше чем трекерд(не знаю кто быстрее ищет), но бигла я вообще запущенного в системе не чувствую, опять моно "для меня" в лидераx.
Очень много людей опускают вещ даже не попробовав самим. Лично я в моновскиx приложенияx написанныx для линукс плоxиx не видел.
>Лично я в моновскиx приложенияx написанныx для линукс плоxиx не видел.Тут либо везет Вам, либо катастрофически не везет мне. Я не видел ни одного удовлетворяющего меня приложения, написанного на Mono. Хотя, отдать должное, они таки начали нормально запускаться.