Оффтоп: ну сидите и хотите дальше. Я не за Сталина и не за комменатора выше. Но ваше "я хочу" это что-то про детское и инфантильное. А я вот хочу квантовую телепортацию уже через пару лет. Прям очень хочу и настаиваю на этом хочу. И думаю много кто мое хочу поддержит.
Нет, к сожалению мир не работает на хочу. Сталин взял власть, не потому что хотел, а потому что взял :) И хотел. Но не только "хочу" определило его.
Не подумайте, что я топлю за какое-то "правильное" мнение, просто мы, люди, такие смешные все со стороны.
Эх. Жаль только поддержку intel маков из 19-ых годов они не стремятся допиливать (оно и понятно), ибо процесс напоминает установку хакинтоша на неподдерживаемое железо и с полу-живым результатом. Но это ладно, это проблемы маководов. Не думал правда, что не смогу поставить линукс на мак :) вот так и "владеем" купленным железом.
Как буд-то маркетолог постмортем писал, а не разработчик. Все по верхам верхов и какие-то вещи уже очевидны из заголовков (кто не рассказывал про ограничения свитчта?). Не торт!
Отлично! Спасибо. Мне всегда нравился foreman, но всегда пугало, что оно не может следить за жизнью процессов, как bluepill, теперь все станет еще проще и красивее :)
Тут понимаете в чем дело, js это такой язык, где правят функции высшего порядка, и потому мы постоянно встречаем передачу функций в аргументах, причем определяются эти функции «на месте»:
_.select(collection, function(e) { return e > 1 })
и все это время что я пробую cs мне очень неудобно писать функции в стиле cs, вот пример:
_.select collection, (e) -> e > 1
потому как сигнатура определения функции очень слабая и еле заметная. Вот собственно и все мои притензии, то есть было бы как в ерланге:
_.select collection, fun(e) -> e > 1
Было бы как по мне гораздо проще :) Именно поэтому я в руби никогда не использую «короткий» синтаксис определения лямбды `->(e) {}`, а всегда использую классический вариант `lambda { |e| }`, потому что сигнатура заметнее :)
Это очень субъективно, но не заметить сигнатуру функции в CS очень просто и мне не нравится это, надеюсь я имею право на такие замечения к авторам языка :)
Ну многое смущает, правда, например эта же история с тем, что я могу написать «x = 1; x?; x????????» и последнее будет валидно и скомпилируется.
Они взяли @ из ruby, мол чтобы не писать this, но при этом в руби я всегда знал, что @ -> это объект, а не метод, потому никогда и не пробовал писать `@field()`, в cs'е же постоянно приходится писать `func()`, что выглядит не естественно и создает только путаницу для руби программистов вроде меня.
Мне не очень понятен синтаксис опредения функции, `(x) -> ()` — выглядит очень неряшливо и легко теряется в коде.
В том же руби: `lambda { |x| }`, или `->(x) {}`
или ерланге: fun(x) ->
или даже в plain-js: 'function() {}'
Короче говоря, cs вроде бы должен был стать удобным и читаемым, но получился перебор, много сахара, слишком много, там где сахар этот вообще не нужен, где-то стало не читаемее, а только хуже.
По поводу '?' я до сих пор не понимаю, причем тут руби :))
Вот смотрите, пишем на cs:
x = 1
if x? then alert(1)
оно раскрывается в js:
if (x != null) {
alert(1);
}
Более того, '?' в кс что-то совсем уж «глупое», ибо я могу написать x?? и оно раскроется в:
if ((x != null) != null) {
alert(1);
}
В руби нет оператора '?', которое можно «впихнуть» в конец переменной :)
в руби можно определить метод с? в конце, так же как и с '!' в конце, но это ни на что не повлияет, это типа средство, позволяющее делать имена методов выразительнее. А в cs это реально функциональный юнит. Так что напрасно говорят, что это из мира руби, это из мира ленивых js разработчиков, которые вечно проверяют все и вся на != null и != undefined… :)
>> операторы диапозона (.., ...),
а в пайтоне такого нет?
>> операторы определения (?),
это вообще бред полнейший, в руби такого «оператора» нет (если вы не о тернарном операторе конечно), просто в руби имя метода может содержать '?'.
>> — оператор доступа (@),
это тихий ужас в cs, в руби @ ссылается на переменную текущего объекта, а в cs оно может ссылаться и на метод, что очень не красиво выглядит.
>> необязательный оператор вызова метода ()
ну и что дальше-то? в cs «метод» без этого оператора все равно не вызовется, про убогий do знаю.
Уже 2 недели пишу на cs и пока так и не понял, мешает он мне или помогает.
Все это отлично, только иногда бывают такие случае — когда поддерживать такого рода легаси просто невозможно, ибо написано оно так — что вообще не позволяет расширять/изменять функциональность без полного переписывания этой каши. Тут то и уходит «понимание» к программисту писавшему это дерьмо.
На самом деле бизнесы ежедневно страдают от того, что код написан плохо — как минимум теряют деньги на переписывания говеных частей другими-новыми программистами. Это конечно контролируемый уровень затрат, но лично при мне компании теряли много денег — нанимая плохого программаста.
Невероятно. Зачем вообще тратить на все это время? Ну будет у вас 1000 юзеров с купленными аккаунтами, что дальше?
Вот вы извините, перед смертью, будете с радостью вспоминать как тратили время на борьбу с трейдарами на торрент трекере? Или таки поймете, что это микро-действия, которые не влияют вообще ни на что?
Даже хорошие программисты частенько ошибаются. Иногда по мелочи. Вспомним MVC, часто бывает так, что большую часть кода можно убрать из контроллеров в модельный слой. Толстые модели можно разбить по мелким модулям. И так далее.
Все это в целом улучшает архитектуру (если широко смотреть на значение этого слова).
Ну я согласен, была какая-то шумиха, но вот если честно — сколько стартапов проиграли из-за этого? И где все эти старт-апы? У меня есть небольшое ощущение, что сама по себе переоцененность ROR — это переоцененность :)) Я надеюсь вы поняли, что я хотел сказать. ROR как и любая другая технология насыщена своими проблемами, я люблю ROR, правда правда, рельсы отлично справляется с массой задач, и вот как видите — многие успешные фреймворки с радостью копируют многие фишки ROR. Понятное дело, что паттерн MVC был придуман еще до ROR, но именно рельсы запустили эту моду.
Посмотрите сколько сейчас MVC фреймворков для того же client-side'а. Хотя я не очень уверен, что именно мода на MVC повлияла на создания бек-боуна и тому подобных, а скорее нужда в RIA, но так или иначе, ROR вполне себе крутая штука, которая смогла немного изменить мир к лучшему. Так что идите в жопу со своими притензиями.
Хочу чтобы меня правильно поняли ... а стоп, это не так работает.
Оффтоп: ну сидите и хотите дальше. Я не за Сталина и не за комменатора выше. Но ваше "я хочу" это что-то про детское и инфантильное. А я вот хочу квантовую телепортацию уже через пару лет. Прям очень хочу и настаиваю на этом хочу. И думаю много кто мое хочу поддержит.
Нет, к сожалению мир не работает на хочу. Сталин взял власть, не потому что хотел, а потому что взял :) И хотел. Но не только "хочу" определило его.
Не подумайте, что я топлю за какое-то "правильное" мнение, просто мы, люди, такие смешные все со стороны.
Эх. Жаль только поддержку intel маков из 19-ых годов они не стремятся допиливать (оно и понятно), ибо процесс напоминает установку хакинтоша на неподдерживаемое железо и с полу-живым результатом. Но это ладно, это проблемы маководов. Не думал правда, что не смогу поставить линукс на мак :) вот так и "владеем" купленным железом.
Еще хочется так поязвить: техническая статья по мейлуршному!
Как буд-то маркетолог постмортем писал, а не разработчик. Все по верхам верхов и какие-то вещи уже очевидны из заголовков (кто не рассказывал про ограничения свитчта?). Не торт!
P.S., что-то пошло не так, но этот комментарий был ответом на habrahabr.ru/post/176947/#comment_6147833
Тут понимаете в чем дело, js это такой язык, где правят функции высшего порядка, и потому мы постоянно встречаем передачу функций в аргументах, причем определяются эти функции «на месте»:
_.select(collection, function(e) { return e > 1 })
и все это время что я пробую cs мне очень неудобно писать функции в стиле cs, вот пример:
_.select collection, (e) -> e > 1
потому как сигнатура определения функции очень слабая и еле заметная. Вот собственно и все мои притензии, то есть было бы как в ерланге:
_.select collection, fun(e) -> e > 1
Было бы как по мне гораздо проще :) Именно поэтому я в руби никогда не использую «короткий» синтаксис определения лямбды `->(e) {}`, а всегда использую классический вариант `lambda { |e| }`, потому что сигнатура заметнее :)
Это очень субъективно, но не заметить сигнатуру функции в CS очень просто и мне не нравится это, надеюсь я имею право на такие замечения к авторам языка :)
Они взяли @ из ruby, мол чтобы не писать this, но при этом в руби я всегда знал, что @ -> это объект, а не метод, потому никогда и не пробовал писать `@field()`, в cs'е же постоянно приходится писать `func()`, что выглядит не естественно и создает только путаницу для руби программистов вроде меня.
Мне не очень понятен синтаксис опредения функции, `(x) -> ()` — выглядит очень неряшливо и легко теряется в коде.
В том же руби: `lambda { |x| }`, или `->(x) {}`
или ерланге: fun(x) ->
или даже в plain-js: 'function() {}'
Короче говоря, cs вроде бы должен был стать удобным и читаемым, но получился перебор, много сахара, слишком много, там где сахар этот вообще не нужен, где-то стало не читаемее, а только хуже.
Но и плюсы конечно тоже есть, видимо :))
Вот смотрите, пишем на cs:
x = 1
if x? then alert(1)
оно раскрывается в js:
if (x != null) {
alert(1);
}
Более того, '?' в кс что-то совсем уж «глупое», ибо я могу написать x?? и оно раскроется в:
if ((x != null) != null) {
alert(1);
}
В руби нет оператора '?', которое можно «впихнуть» в конец переменной :)
в руби можно определить метод с? в конце, так же как и с '!' в конце, но это ни на что не повлияет, это типа средство, позволяющее делать имена методов выразительнее. А в cs это реально функциональный юнит. Так что напрасно говорят, что это из мира руби, это из мира ленивых js разработчиков, которые вечно проверяют все и вся на != null и != undefined… :)
а в пайтоне такого нет?
>> операторы определения (?),
это вообще бред полнейший, в руби такого «оператора» нет (если вы не о тернарном операторе конечно), просто в руби имя метода может содержать '?'.
>> — оператор доступа (@),
это тихий ужас в cs, в руби @ ссылается на переменную текущего объекта, а в cs оно может ссылаться и на метод, что очень не красиво выглядит.
>> необязательный оператор вызова метода ()
ну и что дальше-то? в cs «метод» без этого оператора все равно не вызовется, про убогий do знаю.
Уже 2 недели пишу на cs и пока так и не понял, мешает он мне или помогает.
На самом деле бизнесы ежедневно страдают от того, что код написан плохо — как минимум теряют деньги на переписывания говеных частей другими-новыми программистами. Это конечно контролируемый уровень затрат, но лично при мне компании теряли много денег — нанимая плохого программаста.
Вот вы извините, перед смертью, будете с радостью вспоминать как тратили время на борьбу с трейдарами на торрент трекере? Или таки поймете, что это микро-действия, которые не влияют вообще ни на что?
Все это в целом улучшает архитектуру (если широко смотреть на значение этого слова).
Посмотрите сколько сейчас MVC фреймворков для того же client-side'а. Хотя я не очень уверен, что именно мода на MVC повлияла на создания бек-боуна и тому подобных, а скорее нужда в RIA, но так или иначе, ROR вполне себе крутая штука, которая смогла немного изменить мир к лучшему. Так что идите в жопу со своими притензиями.