Ещё была классная подборка материала — Delphi Russian Knowledge Base. Помню, как я в интернет-центре целый час скачивал её… хотя она весила всего 3 Mb :-D
Зато потом дома можно было без интернета изучать интересный материал.
Два символа вместо одного для самого популярного оператора?
Это конкатенация то самый популярный оператор? Для того, чтобы что-то вставить в строку в 90% случаев интерполяция используется… Теперь она даже в JS есть под названием "String Substitution".
Сейчас по-моему уже для любого языка есть либо REPL, либо Playground, либо и то и то. Так что проблем с быстротой старта в первый результат никаких нет.
стандартный ответ на коментарий о качестве перевода с примерами ошибок
Просто считается, что это надо в личку автору перевода писать. Хотя я такую агрессию не одобряю, т.к. тема улучшения переводов тоже интересная.
Фразу можно понять как — мы сделали наш сайт третьим по посещаемости, среди сайтов на Rails и нас третье место в общем устраивало, мы были довольны.
Ну нет, всё-таки оригинал о том, что фреймворк не стал для них узким местом, несмотря на большую посещаемость. Иначе вторая часть фразы(про сегодняшний день) напрочь теряет смысл.
Why I wouldn’t use rails for a new company — увидеть в переводе — Почему я бы не стал использовать Rails для нового проекта — ну очень неожиданно.
Но если подумать, то это вполне корректная адаптация к российским реалиям. Это у них распространённая практика для каждого нового проекта открывать новую компанию. У нас так не принято. Вот и получается, что речь в статье именно о старте новых проектов, просто для американца начать проект и открыть компанию — это одно и то же.
Раз Вы вынесли это в комментарий, подразумеваю, что Вы хотите обсудить тему улучшения переводов не только с автором, поэтому вставлю свои 2 копейки.
Мы сделали Scribd третьим по посещаемости сайтом на rails, и нас это устроило
В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.
Вообще при переводе необязательно сохранять дословный смысл, потому что языки отличаются не только словами, и буквальный перевод будет выглядеть как у ребят из Edison.
Например, "It was the right bet." переведённая как "И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.
Тренд до середины 2009 года можно использовать для нормировки текущего… Неважно что ещё ищут по такому запросу, но это явно надо вычесть, если хотите увидеть тренд именно по Node.JS
Это всё MS виновата… переиспользуют названия, а потом приходится новичкам по 10 раз рассказывать чем отличается VB от VB.NET, ASP от ASP.NET, ASP.NET от ASP.NET MVC и т.д.
Итак, парадимга ООП не требует наличия запрета доступа к полям или методам
Вы опять потеряли мысль… Доступ к полям через посылку сообщений и прямой доступ к полям — это принципиально разные вещи. И прямого доступа к полям в рамках ООП быть не может.
Возможно, посылая сообщение "получить значение поля такого-то"?
Именно. Фишка в том, что механизм посылки/приёмки сообщений должен быть един в рамках конкретного языка (иначе это уже будет N разных понятий, а не одно — сообщения). Как Вы правильно заметили, это необязательно вызов метода и для полной поддержки ООП наличие методов не требуется. Но в большинстве мейнстрим-языков отправка сообщения — это именно вызов метода.
У нас с вами получается, что ООП это одно, а поддержка ООП это другое, что в общем, логично.
В целом да. Нет ничего плохого в частичной поддержке какой бы то ни было парадигмы в языке. Плохо, что сами парадигмы замыливаются и начинают неверно пониматься. Так мы и скатываемся до понимания в стиле "если есть классы — то это ООП". Гораздо лучше, когда программист осознаёт где границы конкретной парадигмы и какие фичи его любимого языка выходят за эти границы.
Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.
Из третьего пункта следует, что у объектов есть состояние. Из первого пункта — что кроме объектов в программе ничего нет, а из второго — что объекты общаются только через сообщения.
А теперь вопрос: как можно получить доступ к состоянию одного объекта из другого объекта, если они могут взаимодействовать исключительно через сообщения?
Но вообще интересно, в каком языке нормальное ООП есть?
ООП на базе классов — Smalltalk
ООП на базе прототипов — Self
А вообще дело, конечно, не в "нормальности"… а в чистоте парадигмы.
Концепция обязана быть сформулирована предельно конкретно и настолько коротко, насколько возможно… иначе Вы просто будете растекаться мыслью по древу на каждом шагу, подгоняя под неё что угодно.
Двумя комментариями ниже я привёл определение ООП в 3-х коротких предложениях. А теперь попробуйте сформулировать определение ООП так, чтобы оно в полной мере описывало то, что понимается в C++, Java, C# под этой аббревиатурой. Скорее всего, Вы с удивлением поймаете себя на использовании терминов, которые относятся к программированию в целом, а не конкретно к ООП, типа абстракция, полиморфизм и т.д..
Понятно, что финансы конвертируются в ресурсы, выделяемые разработке, и это собственно основной фактор. Но насчёт пятикратного превосходства в реальных задачах хотелось бы узнать поподробнее… Какого рода задачи? И не имело ли место сравнение одного ядра CPU против всех?
Ещё была классная подборка материала — Delphi Russian Knowledge Base. Помню, как я в интернет-центре целый час скачивал её… хотя она весила всего 3 Mb :-D
Зато потом дома можно было без интернета изучать интересный материал.
Вы так пишете, как-будто C++ проще и логичнее, чем Delphi. Хотя по факту там своих "особенностей" выше крыши и гораздо больше, чем у Delphi.
Да, неправильно Вас понял… Насчёт точка vs стрелочка для вызова методов, согласен, что точка удобнее.
Это конкатенация то самый популярный оператор? Для того, чтобы что-то вставить в строку в 90% случаев интерполяция используется… Теперь она даже в JS есть под названием "String Substitution".
Нормальный REPL обещают в Java 9. В общем, слоупочат с официальной поддержкой, как всегда.
Java Playground, Java REPL. Далеко не самые удобные, но хоть что-то…
В качестве первого языка, я бы Java не советовал.
Сейчас по-моему уже для любого языка есть либо REPL, либо Playground, либо и то и то. Так что проблем с быстротой старта в первый результат никаких нет.
Тут нужен баланс… Код должен быть настолько коротким, насколько это возможно без потери выразительности, но не короче :-)
Просто считается, что это надо в личку автору перевода писать. Хотя я такую агрессию не одобряю, т.к. тема улучшения переводов тоже интересная.
Ну нет, всё-таки оригинал о том, что фреймворк не стал для них узким местом, несмотря на большую посещаемость. Иначе вторая часть фразы(про сегодняшний день) напрочь теряет смысл.
Но если подумать, то это вполне корректная адаптация к российским реалиям. Это у них распространённая практика для каждого нового проекта открывать новую компанию. У нас так не принято. Вот и получается, что речь в статье именно о старте новых проектов, просто для американца начать проект и открыть компанию — это одно и то же.
Раз Вы вынесли это в комментарий, подразумеваю, что Вы хотите обсудить тему улучшения переводов не только с автором, поэтому вставлю свои 2 копейки.
В Вашем варианте получилось, что их устроило 3-е место по посещаемости, т.е. ещё дальше от оригинала.
Вообще при переводе необязательно сохранять дословный смысл, потому что языки отличаются не только словами, и буквальный перевод будет выглядеть как у ребят из Edison.
Например, "It was the right bet." переведённая как "И ставка была верной!" выглядит как Promt, потому что по-русски так не говорят. Самое близкое, что мы говорим: "Ставка сыграла!"
Т.е., несмотря на то, что ряд Ваших исправлений в кассу, я бы призвал не гнаться за буквальным соответствием.
Тренд до середины 2009 года можно использовать для нормировки текущего… Неважно что ещё ищут по такому запросу, но это явно надо вычесть, если хотите увидеть тренд именно по Node.JS
Это всё MS виновата… переиспользуют названия, а потом приходится новичкам по 10 раз рассказывать чем отличается VB от VB.NET, ASP от ASP.NET, ASP.NET от ASP.NET MVC и т.д.
Вы опять потеряли мысль… Доступ к полям через посылку сообщений и прямой доступ к полям — это принципиально разные вещи. И прямого доступа к полям в рамках ООП быть не может.
Именно. Фишка в том, что механизм посылки/приёмки сообщений должен быть един в рамках конкретного языка (иначе это уже будет N разных понятий, а не одно — сообщения). Как Вы правильно заметили, это необязательно вызов метода и для полной поддержки ООП наличие методов не требуется. Но в большинстве мейнстрим-языков отправка сообщения — это именно вызов метода.
В целом да. Нет ничего плохого в частичной поддержке какой бы то ни было парадигмы в языке. Плохо, что сами парадигмы замыливаются и начинают неверно пониматься. Так мы и скатываемся до понимания в стиле "если есть классы — то это ООП". Гораздо лучше, когда программист осознаёт где границы конкретной парадигмы и какие фичи его любимого языка выходят за эти границы.
Rails действительно теряет популярность, но никак не в пользу Node.JS или Go. Первый привлекает много новичков, а второй используется только в узких местах и то для Rails-проектов скоро будет гораздо естественнее узкие места закрывать с помощью Crystal/Kemal, а не Go.
Ну а переход от Rails идёт в основном в пользу Ruby/Hanami и Elixir/Phoenix.
Из третьего пункта следует, что у объектов есть состояние. Из первого пункта — что кроме объектов в программе ничего нет, а из второго — что объекты общаются только через сообщения.
А теперь вопрос: как можно получить доступ к состоянию одного объекта из другого объекта, если они могут взаимодействовать исключительно через сообщения?
Это была ответная шутка :-)
ООП на базе классов — Smalltalk
ООП на базе прототипов — Self
А вообще дело, конечно, не в "нормальности"… а в чистоте парадигмы.
Концепция обязана быть сформулирована предельно конкретно и настолько коротко, насколько возможно… иначе Вы просто будете растекаться мыслью по древу на каждом шагу, подгоняя под неё что угодно.
Двумя комментариями ниже я привёл определение ООП в 3-х коротких предложениях. А теперь попробуйте сформулировать определение ООП так, чтобы оно в полной мере описывало то, что понимается в C++, Java, C# под этой аббревиатурой. Скорее всего, Вы с удивлением поймаете себя на использовании терминов, которые относятся к программированию в целом, а не конкретно к ООП, типа абстракция, полиморфизм и т.д..
Понятно, что финансы конвертируются в ресурсы, выделяемые разработке, и это собственно основной фактор. Но насчёт пятикратного превосходства в реальных задачах хотелось бы узнать поподробнее… Какого рода задачи? И не имело ли место сравнение одного ядра CPU против всех?
Хорошо, что теперь и Вам понятно, что в Java нет нормального ООП :-)