раскрыть ветку (52)
Для того, чтобы судить о том, нравится язык или нет, надо знать как минимум 2 (а лучше больше), чтобы было с чем сравнивать. Причём знать не на уровне "читал/википедию смотрел/"hello, world" писал", а в достаточном объёме для сравнения.
Знаете ли вы другие языки, мне неизвестно, заранее простите, если обижаю, но я встречал очень много людей, доказывающих мне преимущества JS при этом, не зная больше ни одного другого языка.
раскрыть ветку (29)
Пишу на PHP (но наверное это то-же ... ну вы поняли), С#, Python, Pascal, чуть-чуть Java
Я вам точно могу заявить, что блин JS, особенно в среде Node, вообще не плох... и просто облеплен ништяками. И точка входа, скажем так проста, даже очень проста.
И как бы похер на типизацию, и супер быстрого выполнения я не жду. Зато я могу пирамиду вызовов нагромодить, и это будет более менее сносно работать. Мне не нужно память размечать, и вообще думать куда я что положу, не нужно лишний код на преобразования писать, у меня из коробки куча всего сразу есть, + ещё куча ништяков, в виде разного рода фреймворков и модулей, и всё удобненько в Npm.
Создать чёто на 5 минут, а многие бизнес задачи решаются за 5 минут, куда проще. Слепил работает, и поехали дальше.
раскрыть ветку (22)
раскрыть ветку (7)
Ну с .net отдельная песьня, вы его в браузер не запихнёте, и за 30 сек сервер с не развернёте. От задачи всё зависит.
Да и лично мне он не прижился, сложно сказать почему конкретно, но не пошло, причём с самого начала.
раскрыть ветку (6)
ну как не запихнете...
другое дело, что это все равно инфраструктура еще далеко не того уровня, что доступна на js
раскрыть ветку (5)
Просто зачем ? ... Я так-то на Ассамблерах пишу... Но зачем ?
Что конкретно можно получить пойдя по такому пути ?
раскрыть ветку (4)
При чем тут ассемблер?
А зачем транспилеры с одного языка на другой существуют?
просто для некоторых шарп удобнее js (ну или привычнее). +wasm по большей части быстрее нативного js.
Таких продуктов уже достаточно.
раскрыть ветку (3)
В моём случае это masm, и это если вдруг мне нужно быстрое выполнение. А так, для типичных бизнес задач, обычно на скорость вообще наплевать. Я как то не заморачиваюсь.
раскрыть ветку (2)
А потом задача обрастает новыми и новыми требованиями и все катится в сраную жопу с этими js,php.
раскрыть ветку (13)
Это вопрос проэктирования, JS предявляет довольно высокие требования из за собственной гибкости. К этому возможно привыкнуть, всё на самом деле просто.
Дебильная логика. Ты путаешь архитектуру и язык. На любом языке можно заархитектурить такую срань, что вообще ничего без костылей и говнокода не внедрить.
раскрыть ветку (11)
раскрыть ветку (10)
Везде она условно одинаковая. И зависит всего от двух вещей - от комьюнити языка (а значит и от его популярности) и от уровня долбоебизма архитектора. Из первого вытекает удешевление поддержки именно жабоскрипта, потому что все вопросы уже заданы, и на каждый уже отвечено по 100 раз. Из второго - удорожание, потому что долбоёбы очень часто имеют амбиции, и часто идут во фронтэнд (медом намазано).
Всё. Больше ни от чего, поверь мне (trust me im engeneer).
раскрыть ветку (9)
Если язык кривой и полон неочевидностей, то не спасет ни огромное комьюнити, ни великолепный архитектор (что, кстати и есть частью "цены").
Иначе все сейчас все и везде писали бы на С++.
поверь мне (trust me im engeneer)
Эксперт из интернета вполне может работать в макдачке и быть ваннаби-программистом.
Только логика и осязаемые примеры, только хардкор)
раскрыть ветку (8)
Приведи мне пример одного языка, в котором нет неочевидностей? Си? Ну, дорогой, я бы тебе насыпал их, но ты и сам знаешь, если пишешь. Дельфи/паскаль? Боже упаси, неочевидностей там больше, чем очевидностей. Луа может быть?
И нет, я не ваннаби, я пишу за денежку уже порядка 8 лет, и лет 20 в общем. Да и работаю не в маке, я в профильной IT.
раскрыть ветку (7)
Приведи мне пример одного языка, в котором нет неочевидностей?
Привести пример, где этих неочевидностей меньше? Любой язык, на котором пишут энтерпрайз. Многие сейчас обидятся, но бапки считать - это не панельки двигать, надежность здесь стоит дороже лени ребят, которые не могут выучить больше одного языка.
раскрыть ветку (6)
Окей, что бывает энтерпрайзнее спринга? Шарпик? Ой вэй, с шарпиком я знаком, да, и я твердо уверен, что жабоскрипт куда аккуратнее.
Да и самый энтерпрайзный ништяк - спринг - вот я пообщался с его операторами. Я не оговорился, программистами их можно назвать весьма условно, это именно операторы фреймворка. Всё, за что они ценятся - это как раз хорошее знание неочевидностей и кривостей, а так же набитая рука на создание "хуяк-хуяк-сервак".
раскрыть ветку (5)
с шарпиком я знаком, да, и я твердо уверен, что жабоскрипт куда аккуратнее
Аргументы будут или опять верить дочери офицера?
Да, сишарп - отличный пример.
раскрыть ветку (4)
Аргументы? Ну, я не считаю, что я должен что-то аргументировать, коли я уж сам ответил на свой же вопрос. Нет, аргументов не будет. Хотя, для поддержания срачика могу написать всего одно слово. Mono.
раскрыть ветку (3)
Какой вы скучный)
> могу написать всего одно слово. Mono.
Что Mono?) Ну, допустим, Core. И мы про языки, а не про платформы.
раскрыть ветку (2)
А вот и попытки унизить пошли. Я услышал всё, что планировал. Когда не остается аргументов - попытайся унизить лично оппонента.
Что моно? Пожалуй, да, плохой пример. Хотя, отказ от мультиплатформенности это та ещё странность, но допустим.
Другое слово - Linq. Довольно странно видеть посреди ООП кода процедурненький DSL.
раскрыть ветку (1)
А вот и попытки унизить пошли.
Так аргументируйте свои высказывания, а не только размахивайте своим огромным опытом в индустрии.
Другое слово - Linq. Довольно странно видеть посреди ООП кода процедурненький DSL.
Вы так говорите, будто это что-то плохое. Только это скорее функциональный, а то и вовсе декларативный язык. Трехэтажные запросы в каком-нибудь Linq2Sql генерить достаточно наглядно. Разве это недостаток?
Хорошо, если не получается сходу вспомнить недостатки у C#, какие есть преимущества перед ним у JS?
Я знаю/знал, но забыл, т.к. не использую, штук 15. Включая 4 ассемблера, лисп и пролог. Про си, плюсы, питон и т.д. даже упоминать не стоит. Жабаскрипт - отличный язык, который прекрасно решает поставленные перед ним задачи. Мне нравится. Хейтят его как раз, преимущественно, ламеры, которые не смогли осилить спек, замыкания и прототипное наследование.
раскрыть ветку (2)
Я бы немного добавила: хейтят ещё и люди, которые не могут понять, что их «правильно» и по «феншую» работает только в рамках конкретных задач.
В принципе обычно это те же ребята, что ругают PHP и уже 10+ лет предвещают ему скорую гибель)
раскрыть ветку (1)
Джаве пророчат позорную смерть уже столько же... Только часть "пророков" уже умерли, а джава активно развивается.
Хорошо. Я знаю ощутимо больше двух языков программирования, на 4 из них активно пишу, еще пяток просто помню.
И, да, я люблю жабоскрипт. Действительно люблю его. Люблю не лепить говноскриптики на jq, а именно язык, и именно много (действительно много) писать на нём.
ЧЯДНТ?
раскрыть ветку (1)
Да всё так. Мне, представьте, тоже нравится JS в своей нише. Проблему я вижу только в том, что многие не понимают, что JS - это нишевый язык, созданный для вполне определённых задач, с которыми он блестяще справляется. Это не язык "общего назначения", как C++, C#, Python или Java
А я встречал много людей доказывающий какой ужасный js. Правда взглянув на их код понимаешь что не js ужасный, а руки из жопы просто растут у горе хейтеров.
раскрыть ветку (4)
Да по мне и так огонь. TS всё только испортит, разве только часть синтаксиса повзаимствовать.
раскрыть ветку (3)
На самом деле нет. Не так давно начал присматриваться к TS, часть классов уже переписал на нём. Есть некоторые раздражающие моменты, но в целом условно-статическая типизация достаточно удобна. Ну и дженерики еще порадовали, они куда гибче, чем даже в котлине. А остальные отличия - чисто сахарок.
раскрыть ветку (2)
Скажем так, я вообще противник типизации.
Это на уровне внутреннего понимания собственного кода, возможно проблемы возникают в группах разработки, но у меня полёт нормальный.
У меня есть propTypes, для такой условной типизации, единственный минус... вот единственный это immunable объекты.
Что конкретно вы получили от TS ? Ну то-есть зачем ? Кроме синтаксического сахара, и чуть более читабельного кода. Хотя если вы хрошо пишите на JS он вполне читабелен.
раскрыть ветку (1)
Именно в команде и возникает необходимость в типизации, в первую очередь. Да и без неё, для себя я уже понимаю, рано или поздно, при наличии хорошей IDE ты начинаешь задумываться "вот бы intellisence работал поумнее, а?".
Да, когда ты пишешь один - ты там царь и бог, и за все косяки винить бы себя, да себя винить не особо хочется. Но в целом я последние годы для себя считаю, что я скорее за статическую типизацию, чем вообще без неё.
Проптайпсы в ТС сделаны через интерфейсы и дженерики. А все типы там можно расширить любых другим количеством типов, и это очень удобно. Касательно иммутабельности - после знакомства с vue я сначала было захотел полную реактивность пропов, но потом задумался, пофантазировал, и понял, что в реакте оно сделано достаточно удобно.
Конкретно от ТС я получил как раз-таки типизацию и ужесточение интерфейса моих классов. Полиморфизм, если можно так сказать. Местами - позволило изменить интерфейс на более приятный и удобный к повседневному использованию.
На js я пишу достаточно годно (по крайней мере тот факт, что прикладные и архитектурные задачи отдают только мне как бы намекает на это), особенно после того, как мы решились переходить на ES6. Но, кмк, ТС со мной надолго.
Не любят за низкое вхождение, как многим кажется, это порождает большое количество быдлокодеров, также за некоторые особенности работы, ну и как по мне крайне маниакальное сообщество, которое любит сраться по поводу и без со всеми, а еще чаще между собой. А пройти собеседование по JS могут только ультра задроты, ибо чтобы разобраться во всех его премудростях надо читать взахлеб десяток книг несколько лет подряд, но такое впринципе во всех языках, в плюсах еще в алгоритмах тебя ебать будут, но это уже совсем другая история.
раскрыть ветку (13)
Не любят за низкое вхождение
пройти собеседование по JS могут только ультра задроты, ибо чтобы разобраться во всех его премудростях надо читать взахлеб десяток книг несколько лет подряд,
Как так-то?)
раскрыть ветку (12)
А из первого вытекает второе. Базовый синтаксис можно рассмотреть за пару суток, какие-нибудь курсики + попрактиковаться, написав пару приложений, все это займет у тебя месяца 3-4 допустим, ну полгода максимум, и на уровне джуна уже можно спокойно работать.
Данный язык, эволюционируя, оброс кучей неочевидными конструкциями (замыкание, область видимости, прототипно-ориентированное программирование), которые в 2019 году либо становятся ненужными (например можно не изучать замыкание, когда есть стрелочные функции, в которые уже передается контекст окружения без юзания bind), либо больше не актуальными (в ES 2015 появились классы, и классы через функции уже можно выбросить).
Но осталось кучу народу, которые каким-то чудесным образом доросли до тимлидов и сеньоров, и искренне считают, что сильный JS разработчик знает и помнит абсолютно все тонкости языка, и умеет компилировать тупые задачки в уме.
И в целом, возникла ситуация, когда уметь писать на JS, и проходить технические собеседования на JS, это 2 абсолютно разных скилла.
раскрыть ветку (11)
Замыкания и прототипное наследование в JS было всегда, это не эволюция, а природа языка.
которые в 2019 году либо становятся ненужными
От того, что появился class, JS не стал Java. Все работает и живет по олдскульным законам прототипного наследования и весело выглядывает среди дырок в сладких костылях новых стандартов.
и искренне считают, что сильный JS разработчик знает и помнит абсолютно все тонкости языка
Он же сильный, как он может не помнить? Или сила в гугле, брат?)
раскрыть ветку (5)
А зачем тащить легаси в виде прототипного наследования?)
Когда есть нормальный синтаксический сахар в ES6.
Я понимаю, если можно потешить свое самолюбие, доказывая новичку, что без этих знаний выжить невозможно)) Но с таким же успехом надо изучать работу транслятора, к примеру V8, и делать код производительным, ведь там тоже есть кучу тонкостей.
Как по мне, если у человека есть стремление изучить инструмент, который он использует, это очень прекрасно, но он не должен становится причиной отсеивания))
Ведь есть кучу других качеств, которые крайне важны: гибкость ума, работа в команде (не быть токсичным говном), писать адекватный код, слушать, слышать и понимать, что нужно пользователю и бизнесу. А на одном знании тонкостей JS не выйти.
Возможно моя философия не самая правильная, но в первую очередь нужно понимать, что это просто инструмент для решения определенных задач, и во многом решают личные качества человека.
Иногда печет с собеседований, на которых только, как на экзамене, зачитывают вопросы и дают однотипные задачки, код в которых, если напишешь такое в проекте, тебе быстро дадут пинка под зад.
раскрыть ветку (4)
> А зачем тащить легаси в виде прототипного наследования?)
Потому что обратная совместимость и тонны этого самого легаси годного качества. Как в прикладном коде, так и в браузерах.
> Но с таким же успехом надо изучать работу транслятора
Так ведь и надо) годные фронтендщики не считают зазорным покопаться в исходниках браузера. Как еще оценивать реальную сложность вычислительных алгоритмов, причины и способы борьбы с перерасхрдрм памяти?
> если у человека есть стремление изучить инструмент, который он использует, это очень прекрасно, но он не должен становится причиной отсеивания
Вы бы хотели слышать такое от медиков про медицину или от полицейских про закон? Полагаю, вряд ли.
Если человек не знает свой инструмент, то он специалист-инвалид, который хоть и может выполнять ряд задач из тех, что доступны здоровому, но качество, время и усилия могут быть иными при прочих равных. У каждого программиста своя степень инвалидности.
Будь ты хоть нобелевский лауриат и вообще свой парень, но если твой код говно и ты не знаешь, как его можно улучшить, то от остальных качеств толку мало.
раскрыть ветку (3)
Со всем соглашусь, кроме зависимости знаний специфики от качества кода, вот это вообще совершенно разные значения. Информации настолько много, и она мутирует быстрее, чем ты ее успеваешь изучить, если конечно оставлять время на жить вообще, в этом случае, трата времени на подробный разбор - слишком расточительно. Возможно это одна из основных причин кадрового голода, мужики с 10-15 летнем опытом, которые варятся в этом с самого начала, ждут аналогичных знаний, от молодых ребят.
раскрыть ветку (2)
Информации настолько много, и она мутирует быстрее, чем ты ее успеваешь изучить
Это проблема зубрилок, которые буквально всё заучивают, а не углубляются. Им вечно не хватает времени, они ноют, что вышел новый фреймворки. Но, блин, все эти чудо-новшества супер-прогрессивных новых стандартов в JS осваиваются за один вечер, язык медленно, но внедряет в себя фишки Java7 пятнадцатилетней давности. Куча фреймворков, которые велосипедят одно и то же разными способами, либо переоткрывают концепции, которым много лет.
Это все не нужно учить, это нужно понимать, угадывать с первых нот. Для этого нужен профессиональный кругозор. Не зная колеса человек никогда не оценит всей глупости перемещения весов на большие расстояния вручную. Замыкание на одной-единственной технологии и точке зрения - это долгая и мучительная смерть специалиста, который боится показаться неумехой и вообще ощущать себя новичком.
это одна из основных причин кадрового голода
Либо бизнес - ССЗБ и не хочет получать конкурентное преимущества благодаря альтернативно одаренным ребятам, либо же ребята эти просто не тянут программирование в самой простой IT-сфере, желая пройти кратчайший путь, получить минимум знаний.
Ведь, если посмотреть на работу врача, это тыкать в людей иголки и писать бумажки. Сложно? Нет. Но тогда ЗАЧЕМ ИХ УЧАТ 10 ЧЕРТОВЫХ ЛЕТ??!
Чтобы знать, когда и чем тыкать в людей.
раскрыть ветку (1)
Это проблема зубрилок, которые буквально всё заучивают, а не углубляются.Факт, но некоторые вещи настолько нелогичны, что другого пути не остается. Но попробуй расскажи об этом HR, у которой написано определение на листочке, и если ты не ответишь ровно так, как написано там, то это неправильно)) Но на это не обращай внимание, так, для смеху.
Это все не нужно учить, это нужно понимать, угадывать с первых нот. Для этого нужен профессиональный кругозор. Не зная колеса человек никогда не оценит всей глупости перемещения весов на большие расстояния вручную.Вот это точно в точку)
Либо бизнес - ССЗБ и не хочет получать конкурентное преимущества благодаря альтернативно одаренным ребятам, либо же ребята эти просто не тянут программирование в самой простой IT-сфере, желая пройти кратчайший путь, получить минимум знаний.Такова работа мозга, затратив минимум усилий, получить максимум результата. Ну или насмотрелись на 6-значные цифры в окладе опытных инженеров, пошли записываться на курсы от GeekBrains, а после выпуска поняли, что без фундаметальных знаний далеко не уеедешь.
Ведь, если посмотреть на работу врача, это тыкать в людей иголки и писать бумажки. Сложно? Нет. Но тогда ЗАЧЕМ ИХ УЧАТ 10 ЧЕРТОВЫХ ЛЕТ??!Где-то читал, что цель высших учебных заведений на данный момент, это выпуск сотрудников кафедры. Если так думать, то все вполне логично, и твое образование ложится на твои плечи.
Простите, а как наличие стрелочных функций и привязка контекста уберегает вас от замыканий?
Область видимости? Может вы имели в виду хойстинг? А то 1-е - это вообще весьма общее для многих языков явление.
А так, с остальным в ветке во многом согласен. хотя в es6 классах нельзя сделать что-то типа
MyClass.prototype.foo=(function(){
const a= {id:0};
return function foo(){
return a.id++;
}
})();
Именно этот пример, конечно, надуманный, но сам прием (возврат подобного замыкания) много где используется.
раскрыть ветку (4)
в es6 классах нельзя сделать что-то типа
Для этого в грядущих стандартах планируют сделать приватные переменные.
раскрыть ветку (3)
Да, знаю. Их и сейчас можно щупать с флагами. Только я не совсем об инкапсуляции. В примере выше "const a" хранит одну ссылку на {id:0} для всех экземпляров класса, тогда как приватной переменной (по крайней мере, по их смыслу) скорее будут создаваться все новые экземпляры {id:0}. Так что поведение здесь разное.
раскрыть ветку (2)
Ну наследование сейчас тоже через прототипы (дети шарят данные родителя), хотя джавовый синтаксис по смыслу требует отдельных объектов.
Мне кажется, что консистентее было бы через замыкания это делать (как TS).
Вы подняли интересный вопрос для меня, повод вгуглиться. Ведь было бы логично и возможность static #foo; предполагать.
раскрыть ветку (1)
Это да. Ну в общем, в stage 3 весьма много хороших пропозлов. Например https://github.com/tc39/proposal-static-class-features ,где и приватная статика, и в бабель их уже завезли. Хотя в принципе можно и сейчас сделать что-то типа:
export const MyClass=(function(){
let somePrivateVariable=0;
return class MyClass{
//какой-то код, использующий somePrivateVariable;
}
})();
Но я забыл, в объявлении класса через функцию есть еще 1 фишка, которой нет через объявления класса: как раз хойстинг. Если у нас есть 2 класса, переменным которых (втч статическим) нужно ссылаться на конструктор/экемпляр соседнего, то через class declaration это сделать не выйдет - будет ошибка. Если же конструктор объявлять через function declaration, то оба конструктора поднимутся в начало lexical environment и смогут и в конструкторе, и в методах ссылаться друг на друга без необходимости городить велосипед.
Плюс классы через функции можно переопределять. Через объявления класса подобная операция вызовет ошибку.
Уверен, что еще что-нибудь забыл...
раскрыть ветку (2)
Назови хотя бы один язык без особенностей и странностей (эсперанто не в счёт - это не язык программирования)?
раскрыть ветку (1)
IT-юмор
5.6K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору