LINUX.ORG.RU

Какой язык программирования лучше начать изучать

 , ,


0

1

Доброго времени суток

Не сочтите за разжигание holy war, да к тому же, наверняка такие темы уже бывали, но хочу вас спросить, сам я немного пишу на php, собственно какой язык программирования лучше начать изучать: ruby, perl или python. Какой из этих языков легче в изучении и мне будет проще его освоить. Если можно то, хотелось бы услышать аргументированные ответы.

Спасибо.

Ответ на: комментарий от nguseff

Потом следует рефакторинг

Поциэнт напрочь отказывается от рефакторинга.

Быстрый гауссов блюр на JS - готов!

к тому же, рефакторинг должен призводится уже по ходу написания, и код в таком виде вообще не должен был выкладываться.

это люди, которые взялись писать большие проекты на JS и поняли

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

aboutcard
()
Ответ на: комментарий от nguseff

Вот, к примеру, позиция самого Айка по этому поводу

A compiler that checks types is obviously conservative (sometimes too conservative), in that it will call a program that fails to type-check an erroneous program, even if that program would have behaved well at runtime for all possible inputs. Dynamic languages are popular in large part because programmers can keep types latent in the code, with type checking done imperfectly (yet often more quickly and expressively) in the programmers’ heads and unit tests, and therefore programmers can do more with less code writing in a dynamic language than they could using a static language.

полностью тут

https://brendaneich.com/2010/08/static-analysis-ftw/

aboutcard
()
Ответ на: комментарий от aboutcard

Ты тёплое с мягким путаешь, как обычно, это не означает, что статическая типизация не нужна. Проблемы с функциями высших порядков тоже надуманные. Они в Java/Rust/C#/Haskell успешно решаются дженериками/выводом типов.

Ты правда не понимаешь, что не так с фразой

type checking done imperfectly (yet often more quickly and expressively) in the programmers’ heads

и что автор тут показывает только вершину айсберга? Понятно, что мы можем обложиться с ног до головы юнит тестами и соглашениями, но проблему это не решит. Цена ошибки при компиляции < цены ошибки в рантайме. Разбираться в коде, где ЯП заставляет тебя определять интерфейсы и типы проще, чем в коде, где ЯП позволяет тебе патчить объекты прямо в рантайме и вообще никак не может предсказать типы до момента X. Костыли с генерацией аннотаций не решают проблему, а выглядят как костыли.

Тот же человек, который на Java пишет говнокод (это человек с низкой культурой программирования безотносительно языка). На JS он напишет такое, что ты скорее в говне утонешь, чем разберешься. А с Java возможно выплывешь.

По поводу Быстрый гауссов блюр на JS - готов!. Я вообще претензий не понимаю. Код решает задачу автора и вполне понятен, там всего-то 180 строчек. Крики «о боже, как это поддерживать», «байтодрочерство, непонятные коэффициенты!» очень забавляют. А если человек даже такое осилить не способен, то я сомневаюсь, что ему стоит заниматься программированием.

nguseff
()
Ответ на: комментарий от nguseff

Цена ошибки при компиляции < цены ошибки в рантайме.

А с другой стороны — скорость разработки и возможность решения задачи (либо принципиальная невозможность)

aboutcard
()
Ответ на: комментарий от nguseff

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

aboutcard
()
Ответ на: комментарий от aboutcard

как ты будешь проверять типы и ловить ошибки типов, если язык позволяет в одном и том же месте кода иметь объект с разным набором атрибутов в зависимости от того, по каким веткам прошла программа в рантайме. Или если объект может быть массивом, объектом или строкой с равной степенью вероятности. Если кому-нибудь придет в голову пропатчить метод X библиотеки Y в рантайме, чтобы у него было меньше кода, как ты об этом узнаешь?

я к тому, что спор глупый. Тебе нравятся динамические языки? ты не одинок. Зачем называть кого-то жабамартышками, если у разных языков разные приоритеты? Агитируй за свой язык, только без фанатизма. Фокусы [1,2,3].map((x) => x.price).reduce((sum, val) => { return sum+val; }, 0) возможны и на Java/C#/Rust, и на JS. Только в случае статически типизированного языка компилятор сделает вывод типов и не даст тебе ошибиться с типом или вызвать не тот метод у x или val без всяких тестов и тайпчекеров.

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

nguseff
()
Ответ на: комментарий от nguseff

как ты будешь проверять типы и ловить ошибки типов, если язык позволяет в одном и том же месте кода иметь объект с разным набором атрибутов в зависимости от того, по каким веткам прошла программа в рантайме.

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

aboutcard
()

Изучай не язык, а библиотеки (Gtk, OpenSSL, SQLite и т.д.).
А язык любой.

Novator ★★★★★
()

Очевидно

Китайский учи. Твой КО!

anonymous
()

Haskell, очевидно

anonymous
()
22 марта 2017 г.

Есть хороший сайт где все объяснят и поможат . https://infars.ru

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.