Ваш любимый язык разработки

Друзья, прошу вас поделиться своими мыслями по поводу самого перспективного языка разработки под нашу любимую ОС Linux.

Вопрос номер один. Правда ли, что за языками сверхвысокого уровня будущее?

Вопрос номер два. Какие основные требования к языку выдвигаете вы?

Идеальный язык программирования для Linux отличается от идеального языка для Windows?

Скрипты это плохо? А что думаете по поводу всяких модных Microsoft Framework?

field_vote: 
Пока без оценки

Самый лучший язык под Linux - наверное, никто с этим спорить не будет - C/C++ :)
Встречный вопрос - что Вы подразумеваете под языками "сверхвысокого" уровня? Java? Python?
Основные требования к языку - чтобы на нем было просто и удобно писать (а не сидеть часами, копаясь в документации и выясняя, где же поставить скобочку). На С++ - удобно и просто. На Asm - удобно, просто (но трудоемко, увы). А вот на Perl - лично мне неудобно.
Идеальный язык под Винду - Турбо-Паскаль ака Дельфи. Потому что там думать не нужно. Клепай знай одну формочку к другой...
Скрипты - это хорошо, пока они выполняют свое предназначение: за пару минут быть написанными для выполнения какой-то мелкой задачки. Когда на них начинают писаться более-менее большие программы - это уже не есть гут.
Фреймворк - это протез. Удобный такой. Естественно выглядит, почти как настоящая нога. Даже шевелится. Но, увы, это всего лишь протез:(

>никто с этим спорить не будет - C/C++

Я буду. Для системного ПО это хороший выбор. Для остального - нет.

Считаю вопрос не корректным. Для разных задач лучше подходят различные языки. Один "идеальный" и "любимый" выбрать невозможно. Также как и "самый перспективный".
По пунктам:
1. правда.
2. возможность быстро написать соответствующую задаче программу.
3. не отличаются. Т.к. идеального языка просто не существует.
4. Скрипты это "хорошо" =). Фреймворки - тоже. Т.к. ускоряют процесс разработки.

В общем поддерживаю, но любимый — это не идеальный. Это тот, который любишь. Вот я люблю Python. Я на нём пока мало писал, когда будет возможность пописать больше, смогу рассказать, за что. Но я бы на нём не писал всё подряд, например если нужна высокая производительность.

Кроме того языки можно разделить на хорошие и плохие, а также находить недостатки в хороших (занятие полезное ввиду того, что языки подлежат исправлению). Это же не правда, что все языки являються идеальными инструментами для своего круга задач. Тем более можно заклемить программы за неадекватное использование языков и фреймворков, что обычно всех и возмущает.

Хм. Ну, насчет "любимого" языка, возможно, вы и правы.
Я, честно говоря, не могу выбрать один конкретный язык =).

Находить недостатки и примеры неадекватного использования действительно нужно.
И языки действительно бывают различными. "Лучше"/"Хуже". Но это уже подробности.
Я имел ввиду, что одного "наиболее перспективного" языка не существует, и различные языки могут быть более/менее подходящими для определенных задач. И только это. Это ни в коем случае не значит, что "все языки являются идеальными инструментами для своего круга задач".

Пожалуй, отвечу и сам. :)

  1. Правда. Это убеждение основывается на том факте, что вычислительные ресурсы гораздо дешевле времени программиста. Если мы говорим о промышленном программировании, то за языками сверхвысокого уровня будущее. Хотя, это не отменяет любителей, которые будут создавать великолепные программы на любых языках.
  2. Тут как бы все просто. :) Язык должен быть легким в изучении, не допускать неоднозначного использования своих лексических конструкций, должен брать на себя то, что компьютер может сделать лучше человека. Например, сам следить за возможными переполнениями буфера, SQL-инъекциями и т.п. Т.е. максимально исключать человеческий фактор. Не забудем и о производительности. Впрочем, это все больше требования к интерпретаторам и конкретным реализациям, нежели к самому языку. А еще он должен мне нравится субъективно. :) Например, я не могу терпеть символ «$» у переменных в PHP, а кому-то нравится. Или мне не очень нравится идея с отступами в Python, а питонистам очень нравится.
  3. Конечно, отличается. Идеальный язык должен максимально эффективно использовать особенности операционной системы, ее конкретные сильные стороны.
  4. Скрипты — и это хорошо, и плохо, но пользы от них намного больше. Например, не надо тратить время на компиляцию, скрипты из непроверенных источников легче поддаются аудиту, нежели бинарники, скрипты легко переносимы между платформами и т.п. Недостатки — производительность. Сторонники проприетарного ПО приведут еще проблемы с защитой интеллектуальной собственности.

    Фреймворки — это замечательно. :) Но только тогда, когда человек сначала обучается на самом низком уровне, потом приходит к пониманию необходимости использовать фреймворк. Например, можно начать изучать JavaScript и основы AJAX, а можно сразу изучить jQuery. В втором случае, думаю, вреда будет больше. :)

    Подведу итог. Самым интересным языком в плане развития мне кажется Ruby. Ему еще есть куда развивается, но общее направление мне кажется верным. :) Кроме этого, можно привести еще и Python.

если отвечать на вопрос прямо тогда shell-скрипт (читать Мастер Фу и десять тысяч строк).
если смотреть с другой стороны нужно использовать более высокоуровневые языки программирования.
а если отвечать подумав тогда для каждой задачи нужно выбирать свой язык.

Как я хотел ответить так же! Ну что ж - Ваш ответ исчерпывающий и полностью созвучен моим ощущениям. И я с удовольствием присоединяюсь к нему. Блестяще! Добавить нечего!

Если начнешь учить какой-нибуть язык не зная C/C++ и основ--на всю жизнь останешся лохом -- "Привет мир".

Это шутка такая?
C и особенно C++ - далеко не лучшие языки для обучения.
Если речь идет, конечно, именно о серьезном обучении программированию, а не о изучении основ быдлокодинга.
P.S.: из вашей фразы, кстати, следует, что все программисты, начинавшие свою карьеру до появления C/C++ на всю жизнь остались лохами. Что, мягко говоря, не соответствует действительности.

Это крайне неоднозначное утверждение. Во-первых, "язык С" - это не "язык С++" и, тем более, - не "С/С++". Если для своего времени С был революционным открытием (переносимый, лёгкий, простой, гибкий) и сыграл фундаментальную роль в развитии ОС (всех ОС, не только юниксоподобных), да и железа тоже, то С++ - это уже что-то, во многом противоположное С по своей задумке... А stl - вообще вредительство.

Во-вторых, папой синтаксиса С вся-таки является Алгол. Впрочем, он же - папа и для Паскаля, так что утверждать, что С внёс нечто системообразующее в синтаксис - нельзя. Он внёс туда что-то, это несомненно, но любой язык внёс в синтаксис что-то...

Скажем, С внёс операции "." (адресация члена структуры), "->", "*" и "++" "--". Теперь во многих языках эти операции именно так и обозначаются. Алгол внёс в язык "begin;" и "end;". Перл - внёс понимание того, что дальнейшее продвижение по пути С в части синтаксиса - совершенно безыдейное занятие. Нет более нечитаемого языка, чем Перл. При том, что по всем прочим статьям Перл - язык превосходящий многих, сомнительно, что тот же Питон как-то радикально превосходит Перл. Ну, и т.д.

w495 аватар

На самом деле рано или поздно придется изучать C (но не С++), ибо это некие алгоритмические основы.

w495 аватар

а питонистам очень нравится.

С jQuery я пошел по такому пути и не сильно жалею. Правда, все равно пришел к изучению JavaScript.

w495 аватар

Вопрос номер один. Правда ли, что за языками сверхвысокого уровня будущее?

Да. Ибо многие вещи лучше сделает машина. Но для программиста важно понимание, что именно машина делает.

Вопрос только, что понимается под сверхвысокого уровня --- Lisp, Arc, Prolog, Erlang, Scala, F#, OCaml? Или то, где пользователю не надо задумываться об особенностях ОС и железа, о распределении памяти.

Вопрос номер два. Какие основные требования к языку выдвигаете вы?

1) Простота освоения.
2) Переносимость. Обидно, что мои творения на ASP.NET, я не могу полноценно запустить не на MS.
3) Все зависит от задачи. Язык должен сам по себе провоцировать писать хорошо.
Например PHP и Perl провоцируют а быдлокодинг самими конструкциями языка. Отчасти так же делает Ruby --- слишком много свободы. С провоцирует на хакерские штучки (своими void* something; if(something)) --- правда, читать это потом не реально.

Идеальный язык программирования для Linux отличается от идеального языка для Windows?

Если говорить о языках высокого уровня, то не должен. Python, например везде хорош. Независимость от платформы должна быть в любом хорошем языке (опять таки все зависит от интерпретатора\компилятора).

Если говорить, о языках системного программирования --- то, всего скорее, тоже нет. Отличаться будут библиотеки, но вряд ли язык. Все равно это будет C. На крайний случай С++.

Скрипты это плохо?

Для прикладного программирования --- скрипты это замечательно. Только это должны быть хорошие скрипты. Переносимость обычно выше. Да и понятность тоже. Но вот когда нужна скорость --- скрипты зло.

А что думаете по поводу всяких модных Microsoft Framework?

Для быстрого решения конкретной задачи --- очень хорошо. Но если Вы долго программируете на этом языке, вы должны понимать его основы. STL --- по сути, тоже Framework. И для применения конкретных функций важно знать, что именно за алгоритмы, за ним стоят, и чем они хороши.

--
Как дипломированный лингвист, могу сказать, что языки программирования весьма и весьма походят на естественные языки. У каждого языка, есть некая основа, фундамент, парадигма. Это культура естественных языков и архитектура машины для программных.
Для Русского --- наша культура и реалии нашей жизни.
Для Английского --- аналогично, с поправкой на Англию.
Для С --- архитектура машины фон Неймана.
Для Java --- стековая JVM.
Для Python --- парадигма того, что все является строкой и объектом.
Для Prolog --- логика предиката первого порялка.
Для Lisp, Caml --- лямбда-исчисление.

Очень важно понимать этот фундамент, чтобы пользоваться языком эффективно. В противном случае, вы станете Языковым Монстром (Language Monster) --- человеком, знающим язык, без знания культуры этого языка.

Вопрос номер один. Правда ли, что за языками сверхвысокого уровня будущее?

Да. Ибо многие вещи лучше сделает машина.

Всё гораздо проще: время программиста дороже, чем машинное время. Поэтому можно плюнуть на некоторые потери в производительности машины, если в производительность человека будет выше.

Вопрос только, что понимается под языком сверхвысокого уровня

Хороший вопрос!

1) Простота освоения.

Это глупость. Тогда и высшую математику учить не стоит, хватит арифметики. Эффективный инструмент изучать стоит в любом случае.

Язык должен сам по себе провоцировать писать хорошо.

А как это? Если можно, то примерами.

Идеальный язык программирования для Linux отличается от идеального языка для Windows?

Если говорить о языках высокого уровня, то не должен.

Т.е. тебя не смущает, что у этих ОС разные парадигмы? Например, парадигма "только одна задача, но качественно". В винде эту парадигму очень сложно будет реализовать.

Если говорить, о языках системного программирования --- то, всего скорее, тоже нет. Отличаться будут библиотеки, но вряд ли язык. Все равно это будет C.

Проблема только в том, что "знать С" фактически значит "знать библиотеки С". Сам по себе С очень прост, если не сказать примитивен.

А что думаете по поводу всяких модных Microsoft Framework?

Для быстрого решения конкретной задачи --- очень хорошо. Но если Вы долго программируете на этом языке, вы должны понимать его основы.

Смеёшься? Фреймворк потому и фреймворк, а не библиотека, что несёт в себе какую-то внутреннюю парадигму-идеологию. А значит надо понимать эту парадигму. Основы языка тут не помогут.

Как дипломированный лингвист, могу сказать, что языки программирования весьма и весьма походят на естественные языки.

А какой естественный язык тебе напоминает Haskell? Желательно разъяснить подробно.

w495 аватар

ошибся веткой

w495 аватар


Это глупость. Тогда и высшую математику учить не стоит, хватит арифметики. Эффективный инструмент изучать стоит в любом случае.

Тоже так считал до определенного времени. Но вот проблема: нужно быстро и качественно. И вчера. А дома жена, и пятеро детей. В данном случае goto Ваша первая реплика.

Простота не отрицает эффективности инструмента. Эффективность --- простоты. Тот же erlang достаточно прост. На тему арифметики --- она не так проста, как может показаться. Все зависит от аксиом.


Язык должен сам по себе провоцировать писать хорошо.
А как это? Если можно, то примерами.

Хорошо:

>>> for i in xrange(10):
... if(1 == i):
... continue
... print i

Плохо (goto документация к php):

<?php
for($i = 0; $i != 5; $i += 1)
if (1 == $i)
continue
print $i
?>


"только одна задача, но качественно".

Back to DOS? Я всегда считал линь многозадачной и многопользовательской. Если вы про разницу северных и пользовательских систем, то разговор иной.


Основы языка тут не помогут.

Бессмысленно изучать рельсы без знания Ruby. Сможете дать однозначное определению фремворку? jQuery --- библиотека или фреймворк? А qooxdoo?


А какой естественный язык тебе напоминает Haskell?

Выдрано из контекста. Читайте внимательнее.) Haskell не изучал. (

w495 аватар

Самым интересным языком в плане развития мне кажется Ruby.

Гляньте erlang на досуге. Читаю и охреневаю с него.

Увы, охреневаю от новой ветки (1.9) Руби. :(( Например, теперь под каждым вводом подразумевается, что он может быть в любой кодировке. Например, для UTF-8 нужно указать "магический комментарий" типа:

# encoding: utf-8

А потом для каждого источника, даже для UTF-8, принудительно вызывать метод force_encoding(). 8-\

За совет про Erlang спасибо! Гляну!

Тоже так считал до определенного времени. Но вот проблема: нужно быстро и качественно.

Значит только значит, что для данной конкретной задачи инструмент неэффективен. Используй эффективный. Ах, да! Его тоже придётся учить...

Хорошо:

Вообще-то плохо: перед continue отступ в 8 пробелов (PEP8).
Кроме того, пробелы и табы визуально не различить в большинстве редакторов. Это одна из самых неприятных сторон Python.

Кроме того, Python славится чудесными конструкциями типа

y= [x^2 for x in range (10) if x<2]
x>6 or return

Место конечно экономит не хило и писать быстрее, но поддерживать такой чудный код весьма непросто.

Back to DOS?

Back to UNIX-way.
Пример с архиваторами:
Linux: tar не умеет сжимать данные, но может пакетировать (собирать в один файл). gzip не умеет пакетировать, но один файл сожмёт как нечего делать.
Windows: rar одновременно и пакетирует и сжимает данные.
В данном случае rar вынужден уметь и то и другое, т.к. в винде очень сложно добиться взаимодействия между собой разных программ. Но это выбор винды, её парадигма.

Бессмысленно изучать рельсы без знания Ruby.

Согласен. Но даже досконально зная Ruby, учить рельсы всё равно придётся.

jQuery -- библиотека (исполняется сам), qooxdoo -- фреймворк (выполняет код, написанный для него).

Haskell не изучал.

Тогда заменяем Haskell на erlang. Вопрос остаётся.

w495 аватар

> Кроме того, пробелы и табы визуально не различить в большинстве редакторов. Это одна из самых неприятных сторон Python.

Это проблема редакторов, а не Python.

Вот это как раз хорошо и очевидно:
y= [x^2 for x in range (10) if x<2]

А это, согласен, что очень странно:
x>6 or return
Но, SyntaxError: invalid syntax. Что тут имелось ввиду?

> Но это выбор винды, её парадигма.

Скорее выбор конкретной реализации rar. Мне никто не помешал пользоваться tar в винде или ark в kubuntu.+ Посмотрите на tar -[a|z|Z].

>В винде очень сложно добиться взаимодействия между собой разных программ.

Эмм ... Хочу еще примеров.

На что не ответил --- или читайте вдумчиво письмена выше, или полностью с Вами согласен. Отвечать подробно лень.

w495 аватар

Комментировать

Filtered HTML

  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <strike> <code> <h2> <h3> <h4> <h5> <del> <img>
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.