Форум Tolkien.SU
Паб «Eagle and Child» => Паб «Eagle and Child» => Тема начата: Manveru от 27/11/2006, 13:04:03
-
По идее, это должен быть опрос, но предусмотреть все варианты очень сложно. :)
Хотелось бы собрать базу данных форума - кто на чём программирует, чтобы(в частности) при случае знать, к кому можно пристать с просьбой о помощи.
В конце концов, это просто интересно.
Начну с себя: Pascal, C, C++, Java - средне, Perl, Assembler - плохо.
-
Основная работа на C#. В активе еще Java, немного php, еще учила Prolog, Matlab. С дрожью вспоминаю C и Lisp. Когда-то был еще Pascal, но дай бог хоть что-нибудь вспомнить =) Иногда требуют ActionScript но не в зуб ногой, ни в глаз копытом.
-
php
-
PHP :-/
-
PHP, JavaScript, Basic (смеется).
-
C++;
Java, Pascal - плохо.
-
Последнее время C#. До того C++ (не managed), C, LISP, несколько разных ассемблеров. Еще можно вспомнить Maple ;D
-
Гыыы =) помнится, курсач был - система, работающая с генеологическим древом. Спросила у препода - можно ли древо взять из книги. Он посоветовал хоббитов =) в результате курсач был по трем домам Эдайн =))
-
Программировал когда-то на Visual Basic`e...
-
Васик тоже на что-то, да годится:
http://www.infiltec.com/j-h-wrld.htm (http://www.infiltec.com/j-h-wrld.htm)
-
C#, PHP. Сейчас вот собраюсь Nemerle приручать. ::)
-
C++ (пока не Builder), Pascal (ненавистный), PHP5, ActionScript (Давно не пользуюсь).
-
В школе учила C++ и QBasic, по два семестра каждый. Не помню почти ничего :'(.
-
*делает мечтательное лицо* В школе C++?
-
Основные языки по работе: C/C++
Около полутора лет назад была парочка проектов на Python'е, с тех пор к нему не возвращался.
Имел эпизодический опыт, когда-то давно разбирался или просто изучал в институте: Pascal (Borland Pascal, Delphi), Assembler PDP11, Assembler Intel x86, Бейсик (УК-НЦ-шный), Prolog (Turbo Prolog), Tcl/Tk, Lisp (autoLisp), HTML.
А вообще не в языках дело. Точнее, далеко не только в языках. Если тема только ради статистики - то статистику, конечно, можно по какому угодно параметру собирать. Если же все это ради того, чтобы "при случае знать, к кому можно пристать с просьбой о помощи", то тут нужно скорее говорить не столько о языках, сколько о технологиях программирования и областях применения, об операционных системах и платформах. О библиотеках... И т.д. Ну и о языках, конечно, тоже. :)
Программирование - вообще очень широкое понятие. И я, например, будучи программистом, работающим, в основном, на низком уровне (взаимодействие с оборудованием, драйверы устройств, немного embedded-программирования встраиваемых систем), не очень-то разбираюсь, скажем, в web-программировании и вообще ничего не знаю про программирование под 1С. Опять же, по личному опыту могу сказать, что привыкши писать под Windows, а потом попав под UNIX/Linux, некоторое время смотришь на мир широко открытыми глазами и не знаешь, как сделать самую простую вещь.
Хотя, конечно, используемый язык, часто является показателем того, чем ориентировочно занимается человек. Особенно, если это языки типа PHP, Java или C# :) А вот в отношении того, кто программирует на C++ или Object Pascal, уже так однозначно не скажешь.
-
PHP (сюда же запишем знание основ Perl)
Visual Basic в различных его проявлениях (5, 6, .NET, VBA, VBScript)
С++, C# (немного)
еще с чем-то по мелочи сталкиваться приходилось..
вот, но вообще мое "все" - это веб-разработка, поэтому основной все же PHP. и, что трудно считать программированием, все же припишу сюда отличное знание HTML и CSS... хобби у меня такое мазохистское - странички вручную верстать...
а ну да, и JavaScript, конечно, тоже по мелочи...
-
Может устроим Holy War ;D ;) ?
-
Может устроим Holy War ;D ;) ?
C# vs Java?
-
Хотя, конечно, используемый язык, часто является показателем того, чем ориентировочно занимается человек. Особенно, если это языки типа PHP, Java или C# :)
И чем же (в этих случаях)?
-
Хотя, конечно, используемый язык, часто является показателем того, чем ориентировочно занимается человек. Особенно, если это языки типа PHP, Java или C# :)
И чем же (в этих случаях)?
Ну, под Java, например, вообще глубоко наплевать на железо и платформу. Поэтому если человек знает Java, то он знает, как писать на ней под любой платформой.
-
Хотя, конечно, используемый язык, часто является показателем того, чем ориентировочно занимается человек. Особенно, если это языки типа PHP, Java или C# :)
И чем же (в этих случаях)?
Вообще я, наверное, немного погорячился с такими глобальными обобщениями. PHP используется преимущественно в Web-программировании и более конкретно - в ПО серверной части. А вот про Java и C#, пожалуй, можно сказать только то, что речь идет о чем-то кросплатформенном и высокоуровневом. Но предметная область, вообще говоря, может быть довольно широкой. Так что, наверное, беру свои слова назад.
-
Ellome, если я буду задавать вопрос по Java, вряд ли он будет касаться предметной области. А Reflection - она и в Африке Reflection, и почти всегда нет разницы, для чего она применяется. Основной вопрос - как.
-
Может устроим Holy War ;D ;) ?
C# vs Java?
А также C++ vs Pascal. И особенно, (C# & Java) vs (C++ & Pascal).
В C# для меня важнее сборка мусора и тип object. А большого смысла в Reflection я так и не понял, как и templates в C++.
-
Начинается оффтопик... Ещё одну, что ли, открыть?
Mrrl, Pascal - не выдерживает конкуренции ни с одним языком - ни с шарпом, ни с плюсами. О Яве и говорить нечего. То есть, сам язык-то, может, и неплох, но вот реализация в Delphi... Ходячее извращение.
Для сравнения - две простых программы, с одинаковым GUI, одна на Delphi, другая написана ручками на Assembler, с прямыми вызовами WinAPI. Делфи-программа весит 170Кб, асмовская - 3Кб. Почувствуйте разницу.
Templates в C++ нужны хотя бы из-за STL. Когда не приходится писать заново каждый раз списки и очереди - это так радует! Я оценил это, когда воспользовался аналогом STL в Java - Сollection.
Сборка мусора... Ну да, удобно, с одной стороны. С другой - мне, например, хотелось бы, чтобы была и сборка мусора, и возможность самому чистить за собой. Потому что даже на примере IDE Netbeans видно, как выделение памяти всё увеличивается и увеличивается - несмотря на то, что запущенные процессы отладки убиваются, файлы закрываются, да и вообще...
Reflection предоставляет мощное средство для подгрузки плагинов Run-Time. И, соответственно, выгрузки.
Holy War C++ vs Java не получится точно, пока не создан компилятор под Java и средства системного программирования для неё. Сдается мне, что это не будет сделано никогда - это нарушает один из основных принципов Java - портируемость. Не знаю, что там с C#. По-моему, то же самое.
Тип Object - это сильно, согласен. Впрочем, в плюсах есть аналог - тип указателя void. Всё равно потом кастить приходиться - как и в Java. Но, конечно, wait(), notify(), class() - это неподражаемо.
-
Начинается оффтопик... Ещё одну, что ли, открыть?
Mrrl, Pascal - не выдерживает конкуренции ни с одним языком - ни с шарпом, ни с плюсами. О Яве и говорить нечего. То есть, сам язык-то, может, и неплох, но вот реализация в Delphi... Ходячее извращение.
Тогда почему 80% первокурсников на вступительной контрольной по программированию пишут ее на Паскале (хотя я специально предлагаю при возможности выбрать другой язык)?
Для сравнения - две простых программы, с одинаковым GUI, одна на Delphi, другая написана ручками на Assembler, с прямыми вызовами WinAPI. Делфи-программа весит 170Кб, асмовская - 3Кб. Почувствуйте разницу.
Имеется в виду объем исходного текста? То, что бинарный файл на языке высокого уровня получится больше, не удивительно. Особенно, если на Паскале использовалась какая-нибудь мощная оконная библиотека.
Templates в C++ нужны хотя бы из-за STL. Когда не приходится писать заново каждый раз списки и очереди - это так радует! Я оценил это, когда воспользовался аналогом STL в Java - Сollection.
Не понимаю я этого подхода. Collection это замечательная библиотека, но она реализована через интерфейсы, и не требует создания индивидуального кода для каждого класса. Так и в C можно было написать списки один раз, реализовав их через char*. Правда, потом все равно оказывалось, что удобнее встраивать указатель во вновь создаваемые классы.
Сборка мусора... Ну да, удобно, с одной стороны. С другой - мне, например, хотелось бы, чтобы была и сборка мусора, и возможность самому чистить за собой. Потому что даже на примере IDE Netbeans видно, как выделение памяти всё увеличивается и увеличивается - несмотря на то, что запущенные процессы отладки убиваются, файлы закрываются, да и вообще...
Есть вызов GC.Collect(); - довольно сильно помогает.
Reflection предоставляет мощное средство для подгрузки плагинов Run-Time. И, соответственно, выгрузки.
Действительно.
Holy War C++ vs Java не получится точно, пока не создан компилятор под Java и средства системного программирования для неё. Сдается мне, что это не будет сделано никогда - это нарушает один из основных принципов Java - портируемость. Не знаю, что там с C#. По-моему, то же самое.
Зависит от целей. Тем, для кого критична эффективность, нужны и C++ и ассемблер. А если важнее сборка мусора и динамическая проверка типа, то язык следующего уровня может оказаться пригоднее. Если у меня не хватает головы, чтобы написать проект на C#, то на C++ я его и подавно не напишу.
-
Тогда почему 80% первокурсников на вступительной контрольной по программированию пишут ее на Паскале (хотя я специально предлагаю при возможности выбрать другой язык)?
Учили в школе? :) Я вот, если б мне предложили, тоже не рискнул бы писать контрольную на незнакомом языке. Да и не так плох Паскаль, как его малюют. ;)
Для сравнения - две простых программы, с одинаковым GUI, одна на Delphi, другая написана ручками на Assembler, с прямыми вызовами WinAPI. Делфи-программа весит 170Кб, асмовская - 3Кб. Почувствуйте разницу.
Писанный мной на Делфи keygen для Тв-тюнера весит 17 килобайт, из которых 5 - красивая иконка. :) Это, конечно, не 3Кб, но при наличии отсутствия асмовского компилятора - вполне себе альтернатива. :)
-
Я учу Pascal в школе, второй год изучая C++. После C++ Pascal кажется уродцем каким-то.
-
*делает мечтательное лицо* В школе C++?
Таки да, правда, только для очень желающих с математического факультета. (У нас факультеты были, правда, предметы различались где-то на 15%)
-
Цитировать не буду. Тезисно.
По поводу вопросов сугубо по языку, коли таковые возникнут: Согласен. Я просто говорил, что знание только языка - это очень мало. Более того, как показывает практика, вопросы именно по языку чаще всего возникают в одной и следующих ситуаций:
- на этапе изучения языка или подготовке к какому-нибудь экзамену на сертификат;
- при "копании" в чужом коде иногда встречаются конструкции, которые ты просто редко используешь;
- когда тебе нужны какие-нибудь инструменты языка, которые редко используешь или вовсе не сталкивался с ними.
В большинстве же случаев, как правило, возникают вопросы не по языку, а по библиотекам или технологиям программирования.
По поводу Паскаля и первокурсников: Так уж получилось, что первым языком программирования, который изучает нынешний среднестатистический школьник или студент, оказывается именно Паскаль (что забавно - до сих пор в виде DOS-овского TurboPascal'я). Для многих из "моего" и чуть более старшего поколения первым языком был Бейсик УК-НЦ, для еще более старшего поколения - Фортран. Естественно, пишешь на том языке, которым лучше владеешь.
По поводу размера исполняемого бинарного файла: На ассемблере можно написать все что угодно. Причем при хорошем подходе к оптимизации кода такие программы будут самыми маленькими и наиболее эффективными. Но увы, трудоемкость программирования на ассемблере даже довольно простых вещей слишком высока. Большая часть кода современных операционных систем написаны на С/C++. Что уж говорить о пользовательских приложениях. Ассемблер и сейчас, конечно, используется. Но в очень специфических местах. Горячие же споры на тему "Ассемблер vs языки высокого уровня" затихли еще в 1970-х годах... При нынешней производительности компьютеров и размерах памяти они тем более неактуальны. Вот другое дело споры "компилируемый код на C/C++ vs интерпретируемый на Java" - по сути тот же спор, но уже на новом витке. ;) По поводу портируемости - кстати, есть вполне успешные решения написания портируемого кода и на компилируемом языке. Характерный пример - библиотека Qt. Кроме того, рекомендации придерживаться стандарта С++ тоже никто не отменял (если бы еще разработчики компиляторов к этим рекомендациям прислушивались бы - но это уж совсем тонкости пошли :))
По поводу "сборки мусора": Тут все зависит от того, к какому стилю программирования привык человек. Я привык полностью сам контролировать все ресурсы, которыми располагаю - захватывать их и освобождать. Поэтому когда это делают за меня, мне как-то неуютно и я как-то инстинктивно внутренне не доверяю этой сборке мусора. Однако же те, кто привык работать на более высоком уровне, часто даже не умеют следить за используемыми ресурсами и тем паче не думают об их освобождении. Упаси Эру, если такому программисту приходится переходить язык более низкого уровня. Без слез смотреть невозможно. И на самом деле очень жалко человека.
По поводу шаблонов с С++ и STL: Шаблоны - штука специфичная, но часто полезная. Хотя не могу сказать, что часто ими пользуюсь (в смысле - пишу свои шаблоны). Действительно по болшому счету сталкиваюсь с ними в основном когда пользуюсь STL-ем А вот STL на шаблонах построена. И в этом ее великая идея. Пример со строкой не очень корректен. Свою строку действительно не так уж сложно реализовать на char*. Однако же не строками едиными STL заканчивается. А вот другие STL-ные контейнеры гораздо более сложные. Особенно если вспомнить, что в качестве элементов того же вектора могут быть объекты абсолютно любого типа - от обычных int или char до сложных классов или других контейнеров. И со всеми ними можно управляться абсолютно единообразным образом. Вот тут и есть вся прелесть. Кроме того - STL, это не только контейнеры. Это еще и алгоритмы! Причем алгоритмы тоже могут быть применены к элементам любого типа. И это достигается опять же за счет шаблонов.
И еще в сторону интерпретируемых языков: Мне в таких языках очень не хватает указателей, возможности работы напрямую с памятью и прочих низкоуровневых штук. В свое время это мне создавало значительные трудности в проектах на Python'е.
-
Паскаль и создавался как учебный язык, ни на что большее Вирт не замахивался. У нас в институте первый курс мехмата изучает таки Паскаль, а вот начиная со второго - С, С++ и ООП применительно к нему.
Имхо, шаблоны С++ - вещь зело полезная при написании относительно небольших программ
Горячие же споры на тему "Ассемблер vs языки высокого уровня" затихли еще в 1970-х годах... При нынешней производительности компьютеров и размерах памяти они тем более неактуальны.
Развитие железа стимулирует развитие программ? Опять же имхо, в корне неверный подход, из-за этого мы и имеем сейчас Висту (например).
-
Развитие железа стимулирует развитие программ? Опять же имхо, в корне неверный подход, из-за этого мы и имеем сейчас Висту (например).
Вот-вот. За производительностью надо следить, но если она не критична, то без фанатизма.
А сколько бы не было памяти и ресурсов процессора - менеждеры придумают, чем и как занять всё ;)
-
Паскаль и создавался как учебный язык, ни на что большее Вирт не замахивался. У нас в институте первый курс мехмата изучает таки Паскаль, а вот начиная со второго - С, С++ и ООП применительно к нему.
Понятно, что Паскаль создавался, как учебный язык. Но учиться вполне можно сразу на С/C++, который в тех пределах, в которых обычно дают Паскаль в школе или на 1-м курсе института не сильно отличается от С/C++. Не вижу каких-то особенных педагогических достоинств в том, чтобы сначала изучать Паскаль, а потом С/C++.
Имхо, шаблоны С++ - вещь зело полезная при написании относительно небольших программ
А уж какая это полезная вещь при разработке больших проектов! ;D
Развитие железа стимулирует развитие программ? Опять же имхо, в корне неверный подход, из-за этого мы и имеем сейчас Висту (например).
Любое развитие языков программирования всегда чем-то обусловлено. А не так, что появились новые ресурсы - так давай же их чем-нибудь займем. Переход от ассемблера к языкам выского уровня был продиктован прежде всего существенным упрощением и ускорением разработки программ. Нынешний же переход от компилируемых языков типа C/C++ к интерпретируемым Java-подобным идет под знаменами великой идеи кросплатформенности программ.
-
Ну, на самом деле, с Java нас конкретно обманывают. :) Никакая она, по сути, не кроссплатформенная - VJM всё равно пишется на нативных функциях. :)
Вот если обязать разработчиков любой операционной системы реализовывать встроенную VJM - тогда, конечно, это будет истинная кроссплатформенность.