Еще на тему
Ортодоксальность и целибат
Популярные art
 | арт барышняРейтинг: 2,596,224.3 |
 | красивые картинкиРейтинг: 990,365.7 |
 | FantasyРейтинг: 636,672.8 |
 | Sci-FiРейтинг: 203,990.8 |
 | Мрачные картинкиРейтинг: 157,825.9 |
 | Traditional artРейтинг: 97,739.5 |
 | digital artРейтинг: 20,296.9 |
 | animal artРейтинг: 11,600.1 |
 | Pin-UpРейтинг: 9,534.5 |
 | art сударьРейтинг: 7,586.5 |
Сейчас на сайте
Всего пользователей на сайте: 208
Многие ЯП или технологии (те же .NET & Java) предотвращают большое количество ошибок и предполагают некий стиль или тон написания кода.
В JS наступает сущий ад callback-ов при попытке реализации асинхронности. Почти всегда возникает необходимость тоннами писать unit тесты. Там проблемная реализация ООП. Неочевидности с областями видимости.
При некотором опыте и уровне скила писать норм код можно и на JS. Но порог вхождения в ЯП достаточно низкий и отсюда получаем море говнокода.
В целом согласен, в js не такая строгая типизация и многие моменты, где другой яп руганётся, js слопает.
Но так же надо понимать, что для разных задач подходят лучше разные языки. + Нужно понимать что и для чего ты делаешь. Имхо, очень странно выглядит, когда для работы несколькокилобайтной софтины требуется выкачивать фреймворк, который весит в сотни раз больше. Так что надо исходить из потребностей.
Да, .NET и Java предотвращают ошибки. Но стоит ли это того? С одной стороны, мы получаем необходимость отдельной установки среды, в которой будет выполнятся прога (библиотеки для шарпа, виртуалка для java), с другой стороны, мы получаем более низкий уровень специалистов. Иначе говоря, разработчик встречает меньше проблем. Опять же, с одной стороны это хорошо, ускоряется разработка, выпуск и ближе старт продаж. С другой стороны, разработчик лишается возможности понять то, с чем он работает. Согласитесь, большая часть опыта приобретается при решении проблем и фиксе багов. Разработчик встречает проблему, решает её и получает опыт вкупе с более глубоким пониманием инструмента с которым работает. А это достаточно важный фактор.
В общем, везде есть свои плюсы и свои минусы. И говнокодеров тоже много.
Хотя опять же, зависит от того, остаются они такими или нет.
Я вот, оглядываясь сейчас на проект сделанный в 2012-м году, понимаю тот ужс, который сотворил. Просто потому, что за последние два года поднял свой уровень и теперь способен это увидеть. Сейчас вот потихоньку переписываю его, чтобы на уровне кода всё было в порядке, понятно и удобно.
Хотя на уровне функционала всё прекрасно - пашет два года, все довольны и никаких нареканий. Так что, фактор роста тоже важен.)
А ещё, надо понимать разницу между js и синтаксисом js. Грусно, когда её не видят.
Я не утверждал обратное. Я пытался донести мысль про то, что язык программирования, технология или фреймворк — это все тоже проекты. Проекты, с точки зрения архитектуры и реализации, бывают удачными или не очень. В силу определенных причин (пиар, везение, поддержка крупными компаниям и т.п.) проекты, которые "не очень", иногда становятся достаточно популярными, что бы на них обратили внимание неквалифицированные специалисты. Вот и вся формула получения большей части говнокода.
>> Имхо, очень странно выглядит, когда для работы несколькокилобайтной софтины требуется выкачивать фреймворк, который весит в сотни раз больше. Так что надо исходить из потребностей.
Назовите мне хоть один популярный высокоуровневый ЯП, который работает без LLVM / движка / интерпретатора. Тот же JavaScript сам по себе не запуститься. Более того, если рассматривать все типы ЭВМ, то трудно сказать, что более популярно: виртуальная машина Java или движок JavaScript.
.NET (C#, VB.NET, Visual C++, J#, IronPython и другие) требуют CLR. Java требует JRE. Node.JS требует V8. Продолжать можно очень долго.
Что Я хочу сказать. Если нам по ТЗ не нужна высокая скорость работы и оптимизация, то мы можем использовать почти ЛЮБОЙ популярный высокоуровневый ЯП, так как среди них нету панацеи в виде встроенной VM во все существующие платформы.
>> Согласитесь, большая часть опыта приобретается при решении проблем и фиксе багов.
Соглашусь, при встрече с недоработкой конкретного ЯП или технологии разработчик часто приобретает знания как обходить или решать эту проблему. Но зачем ему такие знания? Зачем разработчику забивать голову способами решения дыр и недочетов в ЯП или технологии? Почему бы просто не писать код и не развиваться в сторону изучения ВОЗМОЖНОСТЕЙ, а не обхода дыр?
Проведем аналогию с авто. Если машина у Вас часто ломается, то, при постоянном самоличном ремонте авто, Вы приобретете знания механика. Но никак не водителя. Я же буду использовать надежное авто и улучшать непосредственно свои навыки езды в то время, как Вы копаетесь в карбюраторе.