Выбор ЯП для задачи.
А для каких типов задач какой ЯП предпочтительней?
Или с другой стороны:
Какие задачи и на каком языке ты решал? А на каком они проще решаются?
С себя начну: десктопные прилады - плюсы и шарп, более ни чего не знаю, а что самое главное, не вижу перспектив узнавать.
ЗЫ: А вообще меня интересует хотя бы тот же Nemerle, где и в чем он кого делает. Python - что за зверь такой. (с практической точки зрения).
ЗыЗы: Эдакое продолжение "Шаблонов в С++" получается.
[SIZE=1]срач считаю открытым[/SIZE]
это я по декстопу.
А вообще, УК, дали бы хоть задачу какую, что бы срались, какой инструмент более православен (провославно-днепропетровен) для решения
В одно время я писал программы с GUI на C++. Одновременно учился использовать ООП. В теории было сказано, что с ООП можно создавать большие программы, можно создавать многократно используемый код. И я надеялся на это...
Но в результате у меня все классы и объекты были связаны таким бесчисленным количеством "ниточек", что получался безобразный монолит, из которого ничего нельзя было изъять. Более того, со временем в программу ничего нельзя было добавить, чтобы в другом месте не отвалилось.
Решил изучить науку - купил книгу GoF, удачно постиг синглетон... Но при прочтении заметил, что "устаревший" SmallTalk со многими задачами справляется проще, чем "прогрессивный" C++. Пытался я этот язык изучать, чтобы использовать его для создания прототипов программ, но, вероятно, неудачно подобрал инструменты.
Ладно, GoF нормально осилить не смог, решил освоить TDD (разработка дизайна на юнит-тестах). Стал читать книжонку Кента Бека. И вот этот негодяй в середине книге говорит: "Сейчас я покажу, как разработать систему для юнит-тестов. Для этого буду использовать Python".
Первым делом я хотел проклять и Кента Бека, и его наработки за то, что он подсовывает никому не нужную экзотику. Но потом всё же решил продолжить читать и понял, что вот же он - язык для прототипов! Кратко и понятно. Как оказалось, это удобный инструмент для того, чтобы учиться понимать разные парадигмы и техники, те же GoF.
Так и думал его использовать, как учебный, но hardcase меня всё время убеждает, что и для других целей Python вполне хорош :)
Поскольку программирвоанием занимаюсь чисто ради лузлов, т.с., то имею всего два проекта.
Один начал: С++ - клиентское приложение для работы с БД на MySQL. общая задумка - автоматизация на предприятии касательно документооборота и атчотоф. Выбор был обусловлен следующими факторами:
а) знанием С/С++ (худо бедно, но)
б) наличием библиотеки для работы с СУБД MySQL (С# тогда только зародился и коннектора не было в природе)
Проект так и не закончил по причине отсутствия инициативы у работодателя и следуеем смене места работы.
Второй: генерация отчетов. сделал на С#. основные цели, кроме генерации этих отчетов, изучить этот волшебный ЯП.
А, еще на Си игру писал. Ради изучения Си. Дета дажи волялась дома. В камоде. На дискетке:) Прастое такое казено: 21 и рулетка (американская)
1. Программа отображения данных, принимаемых от измерительного комплекса, ибо с GUI на Python удобно работать, а скорости тут не требовалось.
2. Программа фильтрации зашумлённых сигналов (фильтры, правда использовал сравнительно примитивные). Так как алгоритмы фильтрации постоянно менялись, то это было удобно.
3. Прототип системы для встраиваемого устройства. Встраиваемое устройство должно было выполнять сравнительно сложную обработку данных, что требовало длительной отладки, да и требования менялись на ходу. При этом перекомпилирование кода и передача его на устройство требовало времени и мешало технике маленьких шажков. Поэтому вначале использовал устройство как тупой передатчик, а всю интеллектуальную часть реализовал на Python в компе, а затем перенёс всё на C++, чтобы устройство могло работать автономно.
А я б вообще бросил бы все и занялся бы музыкой или фотографией или журналистикой. Ну да не о том речь. :)
Nemerle в принципе является универсальным .NET языком, его можно использовать практически везде где используется C#.
А сделать он может в деле создания DSL-ей. Типичный пример DSL-я тут видимо всем известен - LINQ. Другой DSL, поддерживаемый Nemerle, это Computation Expressions - это макро-библиотека создания асинхронных программ. Не так давно появился DSL описания парсеров - PegGrammar, так что теперь можно прямо в программе описывать парсеры всяческих форматов - от CSV до языков программирования уровня C#.
DSL представляет собой высокоуровневое описание задачи, которую решаем, записывать его в терминах классов-методов может быть очень неудобно и эту проблему решают макросы, с помощью которых можно кастомизировать запись наиболее удобным образом.
Мне на венду лицензионную то не хватает, а ты про порше...
А кризис сказывается в том, что я осознал, что остановилось развитие, а направлений, куда хочется двигаться не вижу... как то так.
А что мешает изучать глубже C++ или C#? Ну или Java. Есть какие-то препятствия? Чем они не подходят для "ваяния десктопного софта"?
Ну вот смотри. Я пишу на дельфи, но уже прихожу к мысли, что изучать дельфи глубже неуместно. Уменьшающаяся популярность и спрос говорят мне, что нужно выбирать что-то новое. Что - хз.
Я не знаю чем плох Дельфи, но я же говорил про другие языки.
Разве это относится к этим языкам? Что продвигает Микрософт? Что лежит в основе всяких Qt? Думаю, что на C++ и C# ещё долго будет спрос. Да и популярные они, хотя и не очень модные.
А в чем такая уж разница? Язык можно изучать сколь угодно глубоко, но если человек начинает чувствовать, что он не может прям сейчас взять и съездить в Испанию на две недели, это может на некотором этапе жизни расстраивать. Мол, пора бы уже. И думаешь, куда бы пойти. И не знаешь.
А как это связано с языками программирования?
Эх, мне хорошо - я не хочу в Испанию... Везучий, наверное, человек :)
Мешает изучать их глубже, отсутсвие реальных задач, и наличие "базовых" знаний в этих языках, которое позволяет решать текущие задачи без углубленного изучения языков.
К примеру те же шаблоны - понимаю их суть, но не знаю куда ее применить, изучить бы их поглубже с применением RTTI, да вот задач таких нет, и что самое главное, нет толкового руководителя для этого дела. А самому для себя выдумывать абстрактные задачи и решать их не получается.
А зачем тебе присутствие "реальных задач"? Хорошо же когда их нет.
Естественно, что если нет конкретной цели, то и учёба не пойдёт. Будет цель - будет учёба. Но мне видится, что дело не в языках программирования.
Естественно, что если нет конкретной цели, то и учёба не пойдёт. Будет цель - будет учёба. Но мне видится, что дело не в языках программирования.
Ну да, лень-матушка одолела... как ни возьмусь книжку почитать умную, тут же в сон клонит. А если есть реальная задача, да когда кто то над душой стоит - это все реально стимулирует и к изучению чего то нового.
Если задача состоит в том, чтобы при чтении умных книг не клонило в сон, то я в первом сообщении говорил, что может помочь. Но есть и другая проблема - после восьми часов программирования не уснуть над учебником невозможно :)
Я не монстр, я - теоретик :) И как теоретик, попробую тоже внести предложение.
Чем хорошо знать C++ (и C#) в России (и не только)? Тем что у нас на C++ создаётся бесчисленное количество Legacy code в понимании Майкла Физерса (Michael Feathers). То есть кода без тестов.
К чему ведёт такой код? К трудновыявляемым ошибкам в коде и к сложности внесения изменений в него. Как он зарождается? Как-то так:
http://forum.codenet.ru/showthread.php?t=65773
И вот когда пользователи намучаются с таким кодом, потратят кучу денег и времени на программистов-студентов, которые будут пытаться исправить этот код методом случайных изменений, тогда появится oxotnik333 весь в белом, преобразует весь код в нормальный, выявит и исправит все ошибки, заработает кучу денег и поедет в Испанию на Порше...
Похоже на утопию :)
Продолжу. Код без тестов - это не очень хорошо. Однако, как пишет Стив Макконнелл, более эффективный и быстрый способ обнаружения ошибок - вдумчивая проверка кода (ещё лучше, если она ведётся другим программистом). Естественно, если применять и то и другое, то выявим ещё больше ошибок.
Вот пример:
http://forum.codenet.ru/showthread.php?t=65702
Тут тесты позволили убедиться, что программа работает только для какого-то определённого диапазона входных данных. Выявить то, что она работает некорректно для других данных помогло упрощение алгоритма. По данным того же Макконнелла (да и Кента Бека) выявлять такие ошибки сподручнее в совместной разработке (хотя бы в парной).
Вывод: для борьбы с Legacy code Оксотнику придётся взять помощника. Значит придётся делиться и купить машину дешевле.
Эх, уже не такая красивая утопия, даже в теории...
ЗЫ: а Порше мне не нравится совсем - с безопасностью беда у него, жЫп рамный нужен.
О да, бери Ниссан Патрол в старом кузове, муж сестры ездит на таком 92-ого года, доволен. ;) Вещь. =)))
Типа того. Но одним взглядом не получится. На эту тему и рассуждаю.
Вообще, тут конечно маркетолог нужен, который может предсказать, насколько будут нужны специалисты, умеющие побеждать дремучий легаси код. Если будут нужны, то имеет смысл не забывать C++. Может они уже востребованы, я не знаю.
Ишь, привередливый. Хаммер устроит?
Вообще, тут конечно маркетолог нужен, который может предсказать, насколько будут нужны специалисты, умеющие побеждать дремучий легаси код. Если будут нужны, то имеет смысл не забывать C++. Может они уже востребованы, я не знаю.
На мой взгляд поддержка чужого легаси кода не принесет большой профит, т.к. со стороны заказчика (не программиста/сис.аналитика) доработка до ума, это что то типа некой халтурки для нанимаемого программиста. Иными словами больший вес в глазах заказчика будет иметь человек, который скажет типа "этот год говно, я напишу с нуля и лучше". С другой стороны пример 1С показывает, что поддержка быдлокода довольно профитное дело, но там ценится не сколько программерские знания, сколько бухгалтерские.
Ишь, привередливый. Хаммер устроит?
Фапаю на SsangYong Kyron
Вообще, тут конечно маркетолог нужен, который может предсказать, насколько будут нужны специалисты, умеющие побеждать дремучий легаси код. Если будут нужны, то имеет смысл не забывать C++. Может они уже востребованы, я не знаю.
Маркетолог нафиг тут не упал. Я так понимаю, что речь о том, куда бы податься, где денег в единицу времени больше. Зачем тебе маркетолог для ответа на такой вопрос? И без посторонних понятно, что проблема больше не в легаси, а в личной производительности. Поддержка легаси-кода не единственное, чем занимаются программисты, и каждому своё. Кто-то умеет хорошо поддерживать говна, кто-то умеет быстро писать неговна. Иные знают в тонкостях Java ME или MS Robotics. И не устану повторять: ценится умение программировать, а не знание плюсов. Плюсы сами по себе нафиг никому не упали.
Он даже американцев перестал устраивать, чё оксотнику-то сплавлять? Патрола вполне хватит. Чем не машина?:)
Насколько я помню, примерно то же самое говорил Никлаус Вирт. Он считает, что отладчики вообще не нужны. Мол, в режиме отладки можно найти место, где переменная получает неправильное значение, и исправить это - заткнуть дыру. А реальная проблема в коде так и остаётся.
Вирт писал, что ошибки должны исправляться пониманием работы алгоритма. И для этого язык должен быть удобным. Ну и наизобретал всякие Модулы да Обероны. Финал известен... Всё-таки неохота напрягать голову, если можно запрячь комп.
Кстати, опять касаясь темы статика vs динамика. Можно считать, что статическая типизация является тоже в некотором роде отладчиком, снимая с программиста часть проверок кода. В языках с динамической типизацией все проверки лежат на программисте. [COLOR="Gray"]На правах троллинга: Так какие языки победят? Финал известен... ;)[/COLOR]
Одобряю! Сам уважаю корейцев. Имхо, соотношение цена/качество у корейских машин лучшее.
Видишь ли, есть разница: 1С порождает большое количество быдлокода, являясь де-факто стандартом отрасли. Поэтому от него иные и рады бы избавиться, да заменить нечем. Кроме прочего, поддерживают не продукцию 1С, а грубо говоря пользовательские скрипты и настройки. Поэтому я бы не сказал, что в 1С сплошной легаси-код.
Другое дело, скажем, фотошоп или что-то вроде АСУ, там запросто может оказаться что угодно. Но и тут сложность: кому-то дешевле поддерживать легаси, а кому-то дешевле выбросить и начать с нуля. Вопрос о стоимости поддержки так просто не решить. Поэтому правильнее уметь писать с нуля и сразу хорошо, подыскивая не дорогие проекты в поддержку (их сравнительно мало), а дорогие проекты в разработку. Их больше.
Всегда удивляли две вещи: дизайн Ссанг-Ёнгов и фап на корейские машины. Хотя хз, Ссанг-Ёнг вроде не так быстро дешевеет, может его и есть смысл брать.
Всегда удивляли две вещи: дизайн Ссанг-Ёнгов и фап на корейские машины. Хотя хз, Ссанг-Ёнг вроде не так быстро дешевеет, может его и есть смысл брать.
У меня не большие требования к авто: рама, дизель, не большой расход, не высокая стоимость обслуживания, плюс по мелочи - кондей, АБС. На дизайн мне пофиг абсолютно, на производителя тоже почти что пофиг, кроме китайцев и отечественного автопрома. Собственно из этих соображений и сложился Ссанг-Ёнг - полноценный дизельный рамный жЫп с ценой до миллиона, с расходом 7-10л плюс свистелки-перделки. Фапом это конечно громко названо, просто удовлетворяет абсолютно всем требованиям.
На Кайрон ругались за дурацкую управляемость.
Посмотрел =15&quick[mark_id]=243&quick[group_id]=11518&quick[section_id]=1&quick[year][1]=2005&quick[year][2]=2011&quick[price_usd][1]=&quick[price_usd][2]=&quick[country_id]=1&quick[region_id]=87&quick[city_id]=0"]цены в Москве на это чудо. Дешевеет примерно со скоростью до 90 тысяч в год. Плюс сюда эксплуатационные расходы и получается цифра, которую тебе надо зарабатывать каждый год для того, чтобы в конце срока продать машину и купить новую. В принципе неплохо. А по отзывам как?
На Кайрон ругались за дурацкую управляемость.
2 л. движок 141 кобылка. Если учесть что масса машины <2 т., то для дизеля похоже. Патриот с Ивековским дизелем 10-12 жрет, ну и масса у него более 2т. Вроде с расходом сходится. Другое дело, что обычно паспортный расход и реальный это совсем разные вещи, и реально с прогревами, простоями и т.п. будет в районе 10-12.
Ну мне все равно ближайшие 3 года только фапать остается на Кайрон, ибо жилище еще не обустроено, а там может еще чего нидь выйдет симпотное.
ЗЫ: нафлудили то, нафлудили...
эм. это разве не китайская марка? :eek:
Согласен с доводом. Но это пока так, и это пока так именно у нас.
Есть основания полагать, что ситуация может измениться. Ибо пользующиеся плохим кодом будут проигрывать тем, кто пользуется хорошим.
Моё мнение, что тот, кто из плохого кода не умеет сделать хороший, тот и хороший не умеет писать. Это относится к тем, кто создаёт сравнительно крупные проекты, в которые может потребоваться внести изменения.
Не могу понять, почему умение программировать противопоставляется знанию C++. Цениться умение программировать + хорошее знание определённого языка.
Моё скромное мнение: отладчик больше нужен для низкоуровневых языков, меньше для высокоуровневых.
Мне финал не известен, так как я не считаю, что он был.
Это правильно. А если комп не справляется?
Почему это все? Возможно, в JS так. Python же и до старта многое проверяет, а в рантайме он выявляет ошибки намного точнее, чем это могут C или C++ (про другие языки не знаю). Python чётко покажет место, где было исключение, а программа на C++ молча рухнет, выдав предупреждение от ОС.
51% акций у китайцев, сама контора корейская, завод где то в этой стране.
Но судя по КИА и Хёндай корейцам доверять можно.
Моё мнение, что тот, кто из плохого кода не умеет сделать хороший, тот и хороший не умеет писать. Это относится к тем, кто создаёт сравнительно крупные проекты, в которые может потребоваться внести изменения.
Ты вероятно мало видел плохого кода, иногда бывает проще и полезней написать с нуля.
Скорее больше цениться знание определенных библиотек под конкретный язык, и всех нюансов и косяков требуемой библиотеки.
Не только видел, но и сам писал в большом количестве. Да и до сих пор пишу, если честно :)
Полностью согласен, что бывают ситуации, когда лучше написать с нуля. Но совсем не уверен, что это всегда так.
Тут я не так уверен. Порассуждаю ещё немного теоретически. Для изучения C++ может потребоваться год или два. Для изучения конкретной библиотеки - месяц, грубо говоря. Так ли дорого для крупной компании дать человеку месяц?
Не-а, чистой воды южнокорейская. Из всех южнокорейцев отличается сотрудничеством с мерседесом и совершенно феерическим внешним видом. Ссанг-Ёнги, ИМХО, страшные чуть менее чем поголовно. Спасибо Кену Гринли.
Если расход 2 литра, то рассчитывай на расход меньше 10 литров только по трассе в спокойном темпе и не превышая. Хотя если верить офсайту, то для максимальной динамики крутить двигатель не обязательно. Крутящий момент у того дизеля неплохой, так что кто знает, может и правда неплохая машина. В любом случае не хуже жигулей.
А чего бы не взять что-то сейчас, потом продать и докинуть денег? Или нужда в машине не великая?
А это вообще от конкретной ситуации зависит. Когда-то быстрее написать заново, когда-то отрефакторить то, что есть. Насколько я понимаю, время на работы является определяющим.
Когда дорого, когда не очень. Моё чисто практическое рассуждение: фирме стоит не только зарплата программиста, а ещё и затраты на простой в работе, а они могут быть хоть какими. В общем случае да, выучить особенности библиотеки быстрее, чем язык.