Привет! Так вечерние мысли вслух...
Работаю я в одной крупной американской конторе, на позиции junior .NET developer
И вот стараюсь там, инициативу проявляю, читаю, паттерны осваиваю, TTD
Менеджер мой сказал даже что после года работы дадут middle скорее всего.
Но вот я смотрю на некоторых своих коллег, реально, до их уровня мне не дойти в силу наверно ограниченных способностей что-ли.
Есть у нас такие серьозные товарищи, расскажут что под капотом у async\await, генерация классов по XML, Test first, code last approach, и все это они юзают в реальных проектах, ну то есть гики, причем четко отслеживается тенденция что все они на .NET
Часто читал что мол позор на фирмах, никто не знает чем абстрактный класс от интерфейса отличается.
У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу.
Как у вас с этим на работе? Какой уровень ваших коллег?
Здравствуйте, cocacola, Вы писали:
C>ну то есть гики, причем четко отслеживается тенденция что все они на .NET
C>Как у вас с этим на работе? Какой уровень ваших коллег?
Поработайте еще, опыта наберитесь. Тогда и смените мнение, надеюсь. Из того, что вы назвали ничего крутого нет. Что касается тенденции .NET, мне, наборот, наблюдается, что C#-сты слабее C++-ников и Java-стов.
Мне кажется, это связано с задачами, которые в основном делают на C# — это все больше десктоп-приложения, либо интранет-сайты. Вот и кажется, что понимание асинхронных вызовов что-то нереально крутое.
Здравствуйте, Sash_xp, Вы писали:
S_>Здравствуйте, cocacola, Вы писали:
C>>ну то есть гики, причем четко отслеживается тенденция что все они на .NET
C>>Как у вас с этим на работе? Какой уровень ваших коллег?
S_>Поработайте еще, опыта наберитесь. Тогда и смените мнение, надеюсь. Из того, что вы назвали ничего крутого нет. Что касается тенденции .NET, мне, наборот, наблюдается, что C#-сты слабее C++-ников и Java-стов. S_>Мне кажется, это связано с задачами, которые в основном делают на C# — это все больше десктоп-приложения, либо интранет-сайты. Вот и кажется, что понимание асинхронных вызовов что-то нереально крутое.
В вызовах нет, да.
Человек декомпилит код, и обьясняет чем asyn Task<TResult> отличается от async void под капотом. При этом он гик во Flash, С++ также.
Я не имею ввиду юзать async/await это является круто) понятно что на уровне юзера этого механизма ничего крутого нет. Я имел ввиду когда человек ПОНИМАЕТ, как это утсроено и может все по косточкам разобрать и выплюнуть. И таких у нас не единицы.
Здравствуйте, cocacola, Вы писали:
C>Человек декомпилит код, и обьясняет чем asyn Task<TResult> отличается от async void под капотом. При этом он гик во Flash, С++ также.
Как работает под капотом знать обязательно. Если появляется какой синтаксический сахар, особенно такого масштаба как async/await -- нужно знать принцип работы, как работает с исключениями и прочее. Это первым делом нужно посмотреть, прежде чем использовать.
C>Я не имею ввиду юзать async/await это является круто) понятно что на уровне юзера этого механизма ничего крутого нет. Я имел ввиду когда человек ПОНИМАЕТ, как это утсроено и может все по косточкам разобрать и выплюнуть. И таких у нас не единицы.
Это фигня. Ничего сложного нет. Просто знание фреймворка, как выучить основные классы/функции и особенности их использования. async/await можно сделать и в виде обычных функций высшего порядка.
Реально круто -- это знать в деталях высшую математику, эллиптическую криптографию, знать тонкости алгоритмов и уметь изобретать свои новые алгоритмы. Вот это реально мозг нужен. А выучить как сделали другие в элементарщине -- фигня.
Здравствуйте, cocacola, Вы писали: C>Есть у нас такие серьозные товарищи, расскажут что под капотом у async\await, генерация классов по XML, Test first, code last approach, и все это они юзают в реальных проектах, ну то есть гики, причем четко отслеживается тенденция что все они на .NET
это все фигня.
и тем более я не понимаю когда люди гордятся тем, что они гики. для меня самый точный перевод этого слова — задрот. от задрота толку мало. ему лишь бы цсв потешить, а больше он ничего делать не будет.
Здравствуйте, __kot2, Вы писали:
__>это все фигня.
Верно.
__>и тем более я не понимаю когда люди гордятся тем, что они гики. для меня самый точный перевод этого слова — задрот. от задрота толку мало. ему лишь бы цсв потешить, а больше он ничего делать не будет.
От задротства большой толк. Это, можно сказать, одно из важных в 90% проектах. Не всем изобретать новые алгоритмы, для большинства достаточно уметь использовать то, что придумали умные дядьки.
31.08.2013 0:52, Shmj пишет:
> Реально круто -- это знать в деталях высшую математику, эллиптическую > криптографию, знать тонкости алгоритмов и уметь изобретать свои новые > алгоритмы. Вот это реально мозг нужен. А выучить как сделали другие в > элементарщине -- фигня.
Может и круто, но спрос на нее маленький.
Здравствуйте, cocacola, Вы писали:
C>Как у вас с этим на работе? Какой уровень ваших коллег?
По разному. Работал в конторе, где руководство само было огого уровнем. Соответственно, всегда были требовательны и тянули людей. Работал и там, где всем было пофигу, потому что проекты одноразовые, а заказчики больше распильные. Сейчас есть и те и другие. Причем я бы сказал, что настоящих профессионалов, любящих разработку и всерьез разбирающихся в мелочах, все-таки меньше, чем тех, кто просто делает работу, не особо заморачиваясь.
Вот только с async-ами у нас проблема .Net 4.5 не поддерживается в Windows XP, а там наш софт все еще очень и очень нужен.
cocacola,
Вы переоцениваете сложность получения таких знаний. Это простые знания, никакого rocket science там нет. Что бы досконально понять, как работает тот же async/await вам достаточно просто прочитать пару статей на MSDN. Не тупых туториалов, а именно базовых статей.
Я, например, вообще джавист. И я знаю при этом, как работает async/await. Знаете почему? Потому что мне однажды потребовалось объяснить программисту .Net, как он работает
Вообще, наличие базовых знаний — это именно то, что отличает квалифицированных программистов от неквалифицированных. Хороший программист знает, как оно устроено "под капотом", а потому он легко решит любую проблему, даже если он не задокументирвоана, даже если по ней нет туториалов, и Гугл молчит. Он просто обратится к своим базовым знаниям, и они подскажут ему ответ. А неквалифицированный кодер, у которого таких знаний нет, впадет в ступор, и побежит за помощью у старшему товарищу.
Все споры на тему того, что базовые знания не нужны, раздувают две категории людей:
1) Низкоквалифицированные специалисты, которые ошибочно считают себя крутыми.
2) Высококвалифицированные специалисты, которые изучали базу очень давно, а сейчас уже применяют ее на автомате, бессознательно. То есть они тупо не замечают, что применяют базовые знания. У них уже отточены навыки, доведены до автоматизма, и потому они перестают их воспринимать как навыки.
В любом случае, если вы хотите стать крутым спецом, то вам категорически нельзя слушать ни первых, ни вторых. Учите базу, копайтесь "под капотом", и со временем вы заметите, что выросли настолько, что либо вас уже повысили на работе, либо те вакансии, которые полгода казались неподъемными, сейчас кажутся какой-то ерундой.
Наконец, в C# действительно средний уровень программистов достаточно низкий. Справедливости ради скажу, что он везде низкий. Но в C# оно особенно низок по сравнению с Java/C/C++. Причина — слишком простые задачи. Очень мало в C# задач, когда нужны реально глубокие знания. Поэтому в этой профессии очень много людей из п.1 — низкоквалифицированных, которые ошибочно считают себя крутыми. Поэтому они будут вас со всех сторон отговаривать от обучения основам. Не слушайте их.
Уважаемый, примите как данность Вы — джуниор, пока не отработаете более ~5 лет, как бы не звалась Ваша должность через год, и что бы не говорил Ваш начальник.
Не потому, что Вы — дурак и не хватает способностей, а в силу того, что за меньший срок нереально серьезно поработать с разными технологиями, на разных проектах.
И тогда, Вы поймете, что все, что сами написали выше — ничего сложного, интересного и просто рутина.
А так же научитесь отличать профессионала от гика, и предпочтете работать с первыми.
Если меня спросят, чем отличается абстрактный класс от интерфейса, я тоже пожму плечами и поинтересуюсь у вопрошающего, чем же они отличаются.
Почему? Чтобы узнать, для этого нужно читать другие книжки.
Здравствуйте, cocacola, Вы писали:
C>Как у вас с этим на работе? Какой уровень ваших коллег?
Забавно, что в основном тебе наотвечали люди с противоестественным баттхертом по отношению к C#. Да еще и не по теме. Ты их не слушай. "Stay hungry. Stay foolish", как говаривал Стив Джобс. Читай литературу и учись у коллег. А должности миддла не бойся. Дерзай!
Здравствуйте, cocacola, Вы писали: C>Часто читал что мол позор на фирмах, никто не знает чем абстрактный класс от интерфейса отличается.
Меня всегда этот вопрос в тупик ставил — у абстрактного класса очень мало общего с интерфейсом.
C>Как у вас с этим на работе? Какой уровень ваших коллег?
А че ты хочешь, если задают идиотские вопросы, процитированные выше?
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, namespace, Вы писали:
N>Если меня спросят, чем отличается абстрактный класс от интерфейса, я тоже пожму плечами и поинтересуюсь у вопрошающего, чем же они отличаются.
Вы серьезно? Я скажу. В абстрактном классе можно указывать конкретную реализацию. Все.
Здравствуйте, devcoach, Вы писали:
D>Наконец, в C# действительно средний уровень программистов достаточно низкий. Справедливости ради скажу, что он везде низкий. Но в C# оно особенно низок по сравнению с Java/C/C++. Причина — слишком простые задачи. Очень мало в C# задач, когда нужны реально глубокие знания. Поэтому в этой профессии очень много людей из п.1 — низкоквалифицированных, которые ошибочно считают себя крутыми.
Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Здравствуйте, -n1l-, Вы писали: Р>>Меня всегда этот вопрос в тупик ставил — у абстрактного класса очень мало общего с интерфейсом. N>Фактически да, но если абстрагироваться до их использования, они очень похожи.
abstract class A
{
enum B { }
}
Заметь, сплошная декларация, ни слова о реализации.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, -n1l-, Вы писали:
N>Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Это не совсем так. Тут следует добавить условие, что язык подходит для решения задачи — в этом случае — да, без разницы. Но скажем, клепать сайт на ассемблере будет сложно для любого веб-разработчика, сколько бы он хорош ни был. На питоне или руби — да без проблем.
Здравствуйте, Sash_xp, Вы писали: S_>Это не совсем так. Тут следует добавить условие, что язык подходит для решения задачи — в этом случае — да, без разницы. Но скажем, клепать сайт на ассемблере будет сложно для любого веб-разработчика, сколько бы он хорош ни был. На питоне или руби — да без проблем.
Нет, я имел ввиду другое. Вот например монитор хоара, человеку который с ним хорошо знаком без разницы на каком языке с ним работать.
Здравствуйте, -n1l-, Вы писали:
N>Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Это верно. Но для хороших спецов нужны хорошие задачи. На Java их много, на C# же таки задач мало. Поэтому хорошие спецы оседают в Java, и вымываются из C#. Как следствие — спецы C# слабее в среднем спецов Java.
Ок, но тогда вы просто обязаны ответить на следующие вопросы.
Какие задачи для java вы считаете хорошими?
Какие по вашему мнению задачи решаются на c# кроме сайтов и десктоп приложений, хотя десктоп это все таки не лафа.
Считаете ли вы, что задачи которые решаются на java на c# сделать невозможно?
Решали ли вы какие-то сложные задачи на c#.
Встречали ли вы тех, кто такие задачи решал?
Здравствуйте, Ромашка, Вы писали:
Р>Здравствуйте, -n1l-, Вы писали: Р>>>Меня всегда этот вопрос в тупик ставил — у абстрактного класса очень мало общего с интерфейсом. N>>Фактически да, но если абстрагироваться до их использования, они очень похожи.
Р>
Р>abstract class A
Р>{
Р> enum B { }
Р>}
Р>
Р>Заметь, сплошная декларация, ни слова о реализации.
В смысле ни слова? А какая разница между:
enum B { } и
enum B {A,B,C}
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, namespace, Вы писали:
N>>Если меня спросят, чем отличается абстрактный класс от интерфейса, я тоже пожму плечами и поинтересуюсь у вопрошающего, чем же они отличаются. N>Вы серьезно? Я скажу. В абстрактном классе можно указывать конкретную реализацию. Все.
Не все. Это не полный ответ.
Здравствуйте, samius, Вы писали: S>Не все. Это не полный ответ.
Самое главное отличие, остальное лишь дотошные мелочи и многие из них — следствия главного отличия.
Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие.
То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия.
То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию.
Дополните меня?
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, devcoach, Вы писали:
D>>Наконец, в C# действительно средний уровень программистов достаточно низкий. Справедливости ради скажу, что он везде низкий. Но в C# оно особенно низок по сравнению с Java/C/C++. Причина — слишком простые задачи. Очень мало в C# задач, когда нужны реально глубокие знания. Поэтому в этой профессии очень много людей из п.1 — низкоквалифицированных, которые ошибочно считают себя крутыми.
N>Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Язык действительно безразличен, но он образует вокруг себя некое сообщество.
Почему-то как только мы перешли от С++ на C# стало намного сложнее найти хороших спецов.
Вроде кандидатов больше, а вот выбирать почти не из чего...
Здравствуйте, -n1l-, Вы писали:
N>Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие.
Ни разу не статический, а такой, который нельзя инстанцировать.
N>То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия. N>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию. N>Дополните меня?
Самое главное отличие, пожалуй, то, что абстрактный класс жестко задает ветвь наследования, в то время как интерфейс может быть реализован в любых иерархиях. Ну и применительно к C#, интерфейс может поддерживаться и структурами, тогда как абстрактный класс и его производные — однозначно ссылочные типы.
Здравствуйте, cocacola, Вы писали:
C>Есть у нас такие серьозные товарищи, расскажут что под капотом у async\await, генерация классов по XML, Test first, code last approach, и все это они юзают в реальных проектах, ну то есть гики, причем четко отслеживается тенденция что все они на .NET
Вообще все эти фигнюшки не говорят о крутости специалиста. Да, знание всяких нюансов использования языка и библиотек отличает новичка он среднечка, но не более того.
Очень крутой программист от прошаренного мида отличается эффективностью работы, стабильностью кода, а главное — выбором наиболее подходящей для конкретной задачи архитектуры.
Здравствуйте, MxMsk, Вы писали:
N>>То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия. N>>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию. N>>Дополните меня? MM>Самое главное отличие, пожалуй, то, что абстрактный класс жестко задает ветвь наследования, в то время как интерфейс может быть реализован в любых иерархиях. Ну и применительно к C#, интерфейс может поддерживаться и структурами, тогда как абстрактный класс и его производные — однозначно ссылочные типы.
Всегда считал что главное — это наличие состояния. В интерфейсе нет работы с состоянием. Ну и возможность частичной реализации тоже. Хотя для последнего, например, в Java 8 будет новое ключевое слово default, которое позволит частично реализовывать интерфейс.
Здравствуйте, sharpcoder, Вы писали:
S>Очень крутой программист от прошаренного мида отличается эффективностью работы, стабильностью кода, а главное — выбором наиболее подходящей для конкретной задачи архитектуры.
Хахаха, то есть что вы сейчас сказали? Примерно следующее: "Крутой специалист круто потому, что он принимает правильные решения". А вы не хотите задуматься, за счет чего он принимает правильные решения? Совершенно верно — благодаря знанию базовых вещей. Например, как можно принять правильное решение какой XML парсер использовать, если человек не понимает в чем разница между DOM и стриминговыми парсерами? Да никак, он не сможет принять такое решение. Или что выбрать — блокирующее или неблокирующее IO? Или что выбрать под конкретную задачу — ArrayList или LinkeList, если он не знает алгоритмической сложности операции поиска по индексу и вставок/удалений?
На базовых знаниях все и строиться. Это как фундамент дома — низкоквалифицированные специалисты его не видят, и думают, что это что-то эфемерное и ненужное. А грамотные специалисты понимают, что это основа основ.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, samius, Вы писали: S>>Не все. Это не полный ответ.
N>Самое главное отличие, остальное лишь дотошные мелочи и многие из них — следствия главного отличия.
Не согласен. Даже если взять чисто абстрактный класс, он уже будет отличаться от интерфейса даже при отсутствии реализации каких либо методов.
N>Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие.
Зачастую (в том же дотнете) это непересекающиеся вещи.
N>То, что интерфейс — набор сигнатур говорится везде и сразу и это опять же часть первого отличия.
Наборы сигнатур — это как раз общее, а не отличающее.
N>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию.
Для интерфейса тоже можно пользоваться всякими фишками наследования. Это относится к общему.
N>Дополните меня?
Хотя бы то что класс можно унаследовать лишь от одного класса, но реализовать множество интерфейсов.
Интерфейс не может содержать объявления кроме методов, свойств и событий экземпляра, а абстрактный класс может содержать все остальное.
Я докапался до того что слово "все" обычно подразумевает завершение перечисление отличий. А их вон еще сколько. И я ведь не все еще назвал.
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, MxMsk, Вы писали:
MM>>Самое главное отличие, пожалуй, то, что абстрактный класс жестко задает ветвь наследования, в то время как интерфейс может быть реализован в любых иерархиях. Ну и применительно к C#, интерфейс может поддерживаться и структурами, тогда как абстрактный класс и его производные — однозначно ссылочные типы. T>Всегда считал что главное — это наличие состояния. В интерфейсе нет работы с состоянием.
Важно не то что в интерфейсе нельзя объявить поле. Важно то, что подразумевается интерфейсом в смысле интерфейсом взаимодействия, т.е. API класса/интерфейса.
Если взять, например, какой-нибудь IList, то очевидно что он либо работает наполовину, либо оперирует внутренним состоянием. Потому в этом аспекте нам не важно, был ли IList интерфейсом, или абстрактным классом. И то и другое подразумевает наличие состояния под капотом.
Здравствуйте, techgl, Вы писали:
T>Всегда считал что главное — это наличие состояния. В интерфейсе нет работы с состоянием. Ну и возможность частичной реализации тоже. Хотя для последнего, например, в Java 8 будет новое ключевое слово default, которое позволит частично реализовывать интерфейс.
Совсем необязательно, чтобы абстрактный класс имел состояние. Например, он может выполнять некоторую функцию, которая кастомизируется виртуальными методами. Плюс, добавляется еще специфика языка/платформы. В MSDN есть такой раздел для .Net.
Здравствуйте, cocacola, Вы писали:
C>У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу. C>Как у вас с этим на работе? Какой уровень ваших коллег?
Вспомнился случай по этому поводу.
Работал у нас один чел, проект был связан с аддоном для Outlook, соответственно COM, ATL и все такое. Чел реально шарил в этом деле, использовал кучу недокументированных функций, все работало зашибись. Потом он перешел на другое место, а через полгода — с выходом нового SDK все работать перестало, т.к. какие-то недокументированные функции перестали существовать, что-то еще поменялось и пр. Реально сидеть с этим остальным было влом, в итоге проще оказалось все переписать, чем разбираться.
А так да, бывают гики готовые сидеть над проектом сутками (находка для начальства, особенно если они не требуют оплаты переработок ), есть обычные парни, в свободное время занимающиеся чем-то другим.
По большому счету, среднего уровня хватает для 95% задач, хотя в конторе нужны и 1-2 профи для особо сложных случаев
Здравствуйте, MxMsk, Вы писали:
MM>В MSDN есть такой раздел для .Net.
Сомнительный аргумент в пользу "Do favor defining classes over interfaces"
In later versions of your library, you can safely add new members to classes; you cannot add members to interfaces without breaking existing code.
Если учесть что интерфейс разрешает лишь методы/свойства/события и их аналогами в абстрактном классе будут абстрактные методы/свойства/события, то не сломав существующий код мы не можем добавить в абстрактный класс ничего абстрактного.
А раз нам надо добавлять неабстрактные методы/свойства/события и мы об этом заранее знаем, то зачем выбирать интерфейс?
Здравствуйте, bkat, Вы писали:
B>Почему-то как только мы перешли от С++ на C# стало намного сложнее найти хороших спецов. B>Вроде кандидатов больше, а вот выбирать почти не из чего...
а мы вот перешли на scala, так это вообще караул — спецов просто нет, ни хороших, ни плохих, хоть обратно на яву возвращайся
Здравствуйте, -n1l-, Вы писали:
N>Фактически да, но если абстрагироваться до их использования, они очень похожи.
чем ? ну да, и тому и другому требуется реализация, все, больше ничего общего
Здравствуйте, devcoach, Вы писали:
D>Хахаха, то есть что вы сейчас сказали? Примерно следующее: "Крутой специалист круто потому, что он принимает правильные решения". А вы не хотите задуматься, за счет чего он принимает правильные решения? Совершенно верно — благодаря знанию базовых вещей
нет, благодаря опыту
D>Например, как можно принять правильное решение какой XML парсер использовать, если человек не понимает в чем разница между DOM и стриминговыми парсерами? Да никак, он не сможет принять такое решение. Или что выбрать — блокирующее или неблокирующее IO? Или что выбрать под конкретную задачу — ArrayList или LinkeList, если он не знает алгоритмической сложности операции поиска по индексу и вставок/удалений?
это вообще что-то типа азбуки, ты еще укажи, что клавиатурой надо уметь пользоваться
D>На базовых знаниях все и строиться. Это как фундамент дома — низкоквалифицированные специалисты его не видят, и думают, что это что-то эфемерное и ненужное. А грамотные специалисты понимают, что это основа основ.
я не понимаю, что такое "базовые знания", то что ты выше указал это ну максимум юниор какой-нить зеленый имеет право не знать
Здравствуйте, samius, Вы писали:
S>Сомнительный аргумент в пользу "Do favor defining classes over interfaces"
Да я не настаиваю. Разместил больше для информации
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, -n1l-, Вы писали:
N>>Т.е. то, что абстрактный класс в самом деле — статический класс можно узнать и помнить, но все эти фишки умещаются в первое отличие. MM>Ни разу не статический, а такой, который нельзя инстанцировать.
Так и хочется рихтера вам подарить и тому кто вам плюсик поставил.
Здравствуйте, nightcode, Вы писали:
N>Здравствуйте, -n1l-, Вы писали:
N>>Ок, но тогда вы просто обязаны ответить на следующие вопросы... N>1. чувствуется баттхерт N>2. ты дотнетчик
Это не злость или зависть или желание что-то доказать(на вашем языке баттхерт), это простое непонимание.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, -n1l-, Вы писали:
S>Не согласен. Даже если взять чисто абстрактный класс, он уже будет отличаться от интерфейса даже при отсутствии реализации каких либо методов.
Ну так потому, что он на в самом деле статический.
S>Зачастую (в том же дотнете) это непересекающиеся вещи.
Для языка да, а для компилятора нет.
S>Наборы сигнатур — это как раз общее, а не отличающее.
Нууу ок.
N>>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию. S>Для интерфейса тоже можно пользоваться всякими фишками наследования. Это относится к общему.
Да ну? Что я могу обращаться через класс к интерфейсу и вызывать метод интерфейса?
Нет. Я должен его определить в классе.
N>>Дополните меня? S>Хотя бы то что класс можно унаследовать лишь от одного класса, но реализовать множество интерфейсов.
Это ограничение языка, а не особенность интерфейсов. S>Интерфейс не может содержать объявления кроме методов, свойств и событий экземпляра, а абстрактный класс может содержать все остальное.
Здрас-те пришли к первому отличию.
S>Я докапался до того что слово "все" обычно подразумевает завершение перечисление отличий. А их вон еще сколько. И я ведь не все еще назвал.
Ну так назовите.
Здравствуйте, nightcode, Вы писали:
N>Здравствуйте, -n1l-, Вы писали:
N>>Фактически да, но если абстрагироваться до их использования, они очень похожи. N>чем ? ну да, и тому и другому требуется реализация, все, больше ничего общего
В абстрактном классе можно определить обычный метод с телом, что-то выполняющим и вызывать этот метод из наследника.
Не обязательно каждый метод абстрактном классе помечать атрибутом abstract.
Здравствуйте, -n1l-, Вы писали:
N>Ок, но тогда вы просто обязаны ответить на следующие вопросы. N>Какие задачи для java вы считаете хорошими? N>Какие по вашему мнению задачи решаются на c# кроме сайтов и десктоп приложений, хотя десктоп это все таки не лафа. N>Считаете ли вы, что задачи которые решаются на java на c# сделать невозможно? N>Решали ли вы какие-то сложные задачи на c#. N>Встречали ли вы тех, кто такие задачи решал?
1) "Хорошие задачи" в контексте этого топика, это задачи, которые требуют глубокого понимания базовых принципов.
2) Я нигде не говорил о том, что на C# хороших задач нет.
3) Речь идет лишь о том, что C# это в бОльшей степени сайтики и декстоп, и в меньшей степени сложный server-side, и в еще меньшей степени еще более солжное системное программирование. Как следствие, "хороших" задач в C# меньше в относительном исчислении по сравнению с Java/C/C++. Как следствие следствия — спецы C# в среднем менее квалифицированы.
async/await — хз, как это работает;
volatile — да хз, хрень какая-то
и т.д. и т.п.
Здравствуйте, nightcode, Вы писали:
N>нет, благодаря опыту
А что такое "опыт"?
N>это вообще что-то типа азбуки, ты еще укажи, что клавиатурой надо уметь пользоваться N>я не понимаю, что такое "базовые знания", то что ты выше указал это ну максимум юниор какой-нить зеленый имеет право не знать
Это примеры, сопоставимые с тем, что спросил автор — про async/await. Да, это действительно простые вещи, и я об этом писал выше — никакого rocket science. Да, это действительно должен знать каждый уважающий себя программист.
Но ведь это же не я тут развел спор. Это ваши коллеги утверждают, что дескать "эти знания нам сто лет в обед не сдались".
Здравствуйте, nightcode, Вы писали: N>нет, благодаря опыту
Потрясающий ответ.
— Почему этот старый мудрец такой мудрый?
— Потому что он старый.
N>это вообще что-то типа азбуки, ты еще укажи, что клавиатурой надо уметь пользоваться
Согласен.
N>я не понимаю, что такое "базовые знания", то что ты выше указал это ну максимум юниор какой-нить зеленый имеет право не знать
Вообще под термином "базовые знания" должны подразумеваться алгоритмы и структуры данных и джун их должен знать прежде всего. Но предыдущий оратор явно имел ввиду какие-то специфические знания платформы.
Здравствуйте, devcoach, Вы писали:
D>1) "Хорошие задачи" в контексте этого топика, это задачи, которые требуют глубокого понимания базовых принципов.
Что вы понимаете под базовыми принципами? D>2) Я нигде не говорил о том, что на C# хороших задач нет.
А я не спрашивал есть или нет, я спрашивал "какие"? D>3) Речь идет лишь о том, что C# это в бОльшей степени сайтики и декстоп, и в меньшей степени сложный server-side, и в еще меньшей степени еще более солжное системное программирование. Как следствие, "хороших" задач в C# меньше в относительном исчислении по сравнению с Java/C/C++. Как следствие следствия — спецы C# в среднем менее квалифицированы.
Что вы понимаете под server-side? Что вы понимаете под системным программированием?
Вы встречали людей которые занимаются встраиваемыми системами?
Вы встречали людей, которые пишут драйвера на java?
D>async/await — хз, как это работает; D>volatile — да хз, хрень какая-то D>и т.д. и т.п.
Это уже другая тема.
Здравствуйте, nightcode, Вы писали:
N>а мы вот перешли на scala, так это вообще караул — спецов просто нет, ни хороших, ни плохих, хоть обратно на яву возвращайся
А что вас толкнуло перейти на Скалу, если не секрет? Как принималось это решение?
У нас на Скале пишут GUI, что в принципе, еще кое-как обоснованно — много всяких кложурок надо фигачить в тех же листенерах.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, devcoach, Вы писали:
N>Что вы понимаете под базовыми принципами?
Читайте самый первый пост в топике.
N>А я не спрашивал есть или нет, я спрашивал "какие"?
Что за вопрос? Такие, которые требуют глубокого понимания принципов работы компьютера, порой вплоть до железяк. Пример — погуглите по слову Disruptor.
N>Что вы понимаете под server-side? Что вы понимаете под системным программированием?
Ок, "системное программирование" — не совсем корректный термин. Давайте так — низкоуровневое программирование. "Низость" — понятие относительное. Server-side — все то, что относится к серверу — как обработчики конкретных запросов, так и сам сервер. Когда вам надо, например, захэндлить запрос от клиента внутри IIS, и вы оперируете высокоуровневыми понятиями — энтити там всякие, SQL запросики — это высокоуровневое программирование. Когда вам надо, например, сам сервер написать, и вы оперируете сокетами, массивами байт, паритесь о многопоточности — это инзкоуровневое программирование. Разумеется, есть и промежуточные варианты.
Так вот, чем "ниже" уровень решаемой задачи, тем больше базовых знаний требуется для ее решения.
На C# задачи, в большинстве своем, высокоуровневые, потому программисты могут запросто не знать азов и быть низкоквалифицированными. Какие задачи — такой и специалист.
На C/C++/Java низкоуровневых задач значительно больше ввиду того, что эти языки применимы на разных платформах. Как следствие, спецов, которые знают основы, в относительном исчислении больше.
D>>async/await — хз, как это работает; D>>volatile — да хз, хрень какая-то D>>и т.д. и т.п. N>Это уже другая тема.
Это как раз то, о чем идет речь в топике.
Здравствуйте, devcoach, Вы писали:
D>На C# задачи, в большинстве своем, высокоуровневые, потому программисты могут запросто не знать азов и быть низкоквалифицированными. Какие задачи — такой и специалист. D>На C/C++/Java низкоуровневых задач значительно больше ввиду того, что эти языки применимы на разных платформах. Как следствие, спецов, которые знают основы, в относительном исчислении больше.
Свеном с sql.ru — ты, что ли? Там тебя забанили, сюда прилез?
Здравствуйте, -n1l-, Вы писали:
MM>>Ни разу не статический, а такой, который нельзя инстанцировать. N>Так и хочется рихтера вам подарить и тому кто вам плюсик поставил.
Спасибо, но у меня уже есть. CLR via C#, 3d Edition:
If the class is abstract, the compiler-produced default constructor has protected accessibility;
Этого достаточно для понимания того, что абстрактный класс не является статическим, который не может иметь экземплярного конструктора.
Если недостаточно, можно открыть главу Static Classes, в которой перечислены ограничения, накладываемый на статический класс. В частности:
The class must define only static members (field, methods, properties, and events).
Абстрактный класс легко может объявлять экземплярные члены. Да, собственно, именно такие он и содержит на 99%.
Ок, ну все понятно. Давайте абстрогируемся. Представим, что вы специалист c++, который работает с ком портом считывая с него данные. Данные приходят к вам в виде массива из десятичных чисел типа byte. Далее вы проводите какие-то обычные арифметические операции типа умножения и деления и отсылаете результат в файл.
Я — программист которые эту же задачу решает на асме, но в отличии от вас, предположим мне нужно все эти арифметические операции реализовать. Т.е. у меня задача та же самая, но реализация "ниже" как вы выразились.
А теперь вопрос, могу ли я сказать, что вы как специалист хуже чем я, раз я решаю задачу на языке в котором меньше возможностей?
Второй вопрос, что вам мешает понимать, как работает арифметика компьютера программируя на более высокоуровневом языке.
Еще раз сделаю акцент на вашей логике.
Вы берете разработчика, который пишет в основном сайты на asp.net и начинаете принижать его компетенцию за то, что он не писал каких-то сложных абстрактных серверов и систем. Позже вы эти выводы обобщаете на всех.
Я вот например, абсолютно уверен в том, что программируя на с++ можно вообще не знать как работает программный стек.
Другое дело, что я бы не использовал с++ если бы мне не была критически важна производительность.
Ну ладно, предположим, что специалисты программирующие на с++ все очень круты.
Но java? Java такой же фреймворк как и дотнет? Java то чем обходит?
D>Это как раз то, о чем идет речь в топике.
Мы как бы отошли от контекста топика, если что.
.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
extends [mscorlib]System.Object
{
} // end of class ConsoleApplication1.A.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
extends [mscorlib]System.Object
{
} // end of class ConsoleApplication1.A
В чем отличие? Правильно, от статического класса нельзя наследоваться. Перечитайте рихтера.
.class private abstract auto ansi sealed beforefieldinit ConsoleApplication1.B
extends [mscorlib]System.Object
{
} // end of class ConsoleApplication1.B.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
extends [mscorlib]System.Object
{
} // end of class ConsoleApplication1.A
Здравствуйте, -n1l-, Вы писали:
N>Вы берете разработчика, который пишет в основном сайты на asp.net и начинаете принижать его компетенцию за то, что он не писал каких-то сложных абстрактных серверов и систем. Позже вы эти выводы обобщаете на всех.
Вы совершенно неверно интепретируете то, что я написал выше. Вот вы пишете: "я могу реализовать калькулятор как на высокоуровневом C#, так и на ассемблере". Ну ок, вы пришли к выводу, что все то, что можно сделать с помощью высокоуровневых инструментов, можно сделать и с помощью низкоуровневых. Ну спасибо, что проговорили очевидные вещи. Но я то говорю про обратное — не все, что можно сделать с помощью низкоуровневых инструментов можно сделать с помощью высокоуровневых. Поэтому спец, который знает, как все работает "под капотом", использует высокоуровневые инструменты везде, где это возможно, а где нет — переходит к низкоуровневым. Более того, крайне важный момент — понимание из каких низкоуровневых инструментов составлена высокоуровневый, он принимает более правильные решения о том, какой высокоуровневый инструмент использовать. Благодаря этому же он может лучше прогнозировать, а грамотное прогнозирвоание — один из важнейших скиллов архитектора.
Вот вам простейший пример из недавней практики. Мне нужно было сделать HTTP клиента, который общается с HTTP сервером. Банальщина. Но, мне нужна была особая поддержка обработки серверного ответа 100-Continue. Благодаря моим знаниям того, как работает HTTP протокол, и того, как реализованы два наиболее распространенных клиента, я быстро пришел к выводу, что они мне не подходят. Если бы я этих основ не знал, то я сначала взял бы один клиент, потом написал бы какой-то код, код бы не заработал, я бы его стер, потом взял другой клиент, его бы попробовал, он бы тоже не подошел, и т.д. В итоге — я убил бы кучу времени в никуда. Но я знал основы, поэтому быстро понял, что в лоб эту задачу не решить. И нашел другое правильное решение, не написав ни одной лишней строчки кода.
N>Ну ладно, предположим, что специалисты программирующие на с++ все очень круты. N>Но java? Java такой же фреймворк как и дотнет? Java то чем обходит?
Вы шутите? Кроссплатформенность — слышали про такое7 Только не надо мне говорить про Mono. Что бы оно дозрело до того, что бы компании смело брали его в продакшн, еще лет 10 пройдет как минимум.
То есть инструментарий то что у Java, что у .Net один. Но у .Net я могу применять эти инструменты только под Виндой, а на Java — в любом окружении. Это и предопределяет то, что на Java можно спокойно писать серверные продукты, зная, что они пойдут в наиболее стабильном и востребованном серверном окружении — unix/linux-like операционках.
Здравствуйте, cocacola, Вы писали:
C>Но вот я смотрю на некоторых своих коллег, реально, до их уровня мне не дойти в силу наверно ограниченных способностей что-ли.
пиши больше кода для бога кода!
C>Как у вас с этим на работе? Какой уровень ваших коллег?
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, samius, Вы писали:
S>>Не согласен. Даже если взять чисто абстрактный класс, он уже будет отличаться от интерфейса даже при отсутствии реализации каких либо методов. N>Ну так потому, что он на в самом деле статический.
На самом деле это чушь.
S>>Зачастую (в том же дотнете) это непересекающиеся вещи. N>Для языка да, а для компилятора нет.
Пердлагаю объявить абстрактный класс с абстрактным методом, заменить ключевое слово abstract на static и почитать, что скажет компилятор.
S>>Наборы сигнатур — это как раз общее, а не отличающее. N>Нууу ок.
N>>>То, что для абстрактного класса можно пользоваться всякими фишками наследования, это тоже относится к первому отличию. S>>Для интерфейса тоже можно пользоваться всякими фишками наследования. Это относится к общему. N>Да ну? Что я могу обращаться через класс к интерфейсу и вызывать метод интерфейса?
Что значит обращаться "через класс"? Но да, обращаясь к интерфейсу вы вызываете метод интерфейса, в то время как у класса может быть свой метод с такой же сигнатурой. N>Нет. Я должен его определить в классе.
Естественно.
N>>>Дополните меня? S>>Хотя бы то что класс можно унаследовать лишь от одного класса, но реализовать множество интерфейсов. N>Это ограничение языка, а не особенность интерфейсов. S>>Интерфейс не может содержать объявления кроме методов, свойств и событий экземпляра, а абстрактный класс может содержать все остальное. N>Здрас-те пришли к первому отличию.
Нет, не пришли. Т.к. объявление != реализация.
S>>Я докапался до того что слово "все" обычно подразумевает завершение перечисление отличий. А их вон еще сколько. И я ведь не все еще назвал. N>Ну так назовите.
Пожалуйста. У объявлений в классе можно указывать модификатор видимости. У интерфейса — нет.
Или вам все отличия указать? Боюсь,что я не подписывался. Еще раз. Я лишь опроверг ваш тезис о том что "Все" после одного отличия.
N>.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
N> extends [mscorlib]System.Object
N>{
N>} // end of class ConsoleApplication1.A
N>.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
N> extends [mscorlib]System.Object
N>{
N>} // end of class ConsoleApplication1.A
N>
N>В чем отличие? Правильно, от статического класса нельзя наследоваться. Перечитайте рихтера.
Во-первых, статический класс — это термин высокоуровнего языка, а не CIL. ECMA-335 не содержит упоминания "static class". Если честно, содержит ровно одно в rationale от 11.10.1.4.
А раз это не термин CIL, то искать серьезные отличия на уровне CIL не стоит, т.к. CIL просто не имеет соответствующей специфики для представления статических классов. Вы бы еще в машинных кодах разницу поискали.
Здравствуйте, samius, Вы писали:
S>Во-первых, статический класс — это термин высокоуровнего языка, а не CIL. ECMA-335 не содержит упоминания "static class". Если честно, содержит ровно одно в rationale от 11.10.1.4. S>А раз это не термин CIL, то искать серьезные отличия на уровне CIL не стоит, т.к. CIL просто не имеет соответствующей специфики для представления статических классов. Вы бы еще в машинных кодах разницу поискали.
Угу. Если следовать его логике, то локальные переменные, попавшие в лямбду, надо называть полями класса.
Здравствуйте, devcoach, Вы писали:
D>Вы совершенно неверно интепретируете то, что я написал выше.
Это вы не правильно интерпретируете то, что я пишу.
D>один из важнейших скиллов архитектора.
Вот именно, использования языка в конкретной задаче — это способность людей, а не языка
D>Вот вам простейший пример из недавней практики. Мне нужно было сделать HTTP клиента, который общается с HTTP сервером. Банальщина. Но, мне нужна была особая поддержка обработки серверного ответа 100-Continue.
Внезапно, тоже банальщина ну да ладно.
D>Вы шутите? Кроссплатформенность — слышали про такое7 Только не надо мне говорить про Mono. Что бы оно дозрело до того, что бы компании смело брали его в продакшн, еще лет 10 пройдет как минимум.
Логика.Enabled = true!
Блин я имел ввиду в качестве людей блин, вы вообще следите за мыслью или нет?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, -n1l-, Вы писали:
N>>
N>>.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
N>> extends [mscorlib]System.Object
N>>{
N>>} // end of class ConsoleApplication1.A
N>>.class private abstract auto ansi beforefieldinit ConsoleApplication1.A
N>> extends [mscorlib]System.Object
N>>{
N>>} // end of class ConsoleApplication1.A
N>>
Начинается...
Не ищите сходства там, ищите вон там...
Вы спорите не по существу.
Здравствуйте, samius, Вы писали:
S>Пердлагаю объявить абстрактный класс с абстрактным методом, заменить ключевое слово abstract на static и почитать, что скажет компилятор.
Предлагаю в абстрактном классе объявить статический конструктор.
S>Или вам все отличия указать? Боюсь,что я не подписывался. Еще раз. Я лишь опроверг ваш тезис о том что "Все" после одного отличия.
Да вы по существу ничего не сказали, лишь только мои слова подтвердив.
Все что вы указали, по существу, это первое отличие. В абстрактном классе можно указывать реализацию в интерфейсе нет.
Здравствуйте, samius, Вы писали:
S>Пердлагаю объявить абстрактный класс с абстрактным методом, заменить ключевое слово abstract на static и почитать, что скажет компилятор.
Все компилится на ура.
abstract class A
{
static A()
{
}
public static void GetValue()
{
}
}
static class B
{
static B()
{
}
public static void GetValue()
{
}
}
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, samius, Вы писали:
N>Начинается... N>Не ищите сходства там, ищите вон там... N>Вы спорите не по существу.
Я не спорю с теми, кто не понимает о чем я пишу. Смысл?
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, samius, Вы писали:
S>>Пердлагаю объявить абстрактный класс с абстрактным методом, заменить ключевое слово abstract на static и почитать, что скажет компилятор. N>Предлагаю в абстрактном классе объявить статический конструктор.
По-вашему это докажет что абстрактный и статический класс это одно и то же? Иначе зачем?
S>>Или вам все отличия указать? Боюсь,что я не подписывался. Еще раз. Я лишь опроверг ваш тезис о том что "Все" после одного отличия. N>Да вы по существу ничего не сказали, лишь только мои слова подтвердив. N>Все что вы указали, по существу, это первое отличие. В абстрактном классе можно указывать реализацию в интерфейсе нет.
Ну хорошо, остальные отличия по-вашему несущественные и по существу являются первым отличием. Не забудьте об этом упомянуть на очередном собеседовании.
Я сказал вам что меня беспокоит в вашем ответе. Если вас это не беспокоит, то какие мои заботы?
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, samius, Вы писали:
S>>Пердлагаю объявить абстрактный класс с абстрактным методом, заменить ключевое слово abstract на static и почитать, что скажет компилятор. N>Все компилится на ура.
Это лишь подтверждает что вы не в состоянии прочитать что вам пишут.
Здравствуйте, -n1l-, Вы писали:
S>>Или вам все отличия указать? Боюсь,что я не подписывался. Еще раз. Я лишь опроверг ваш тезис о том что "Все" после одного отличия. N>Да вы по существу ничего не сказали, лишь только мои слова подтвердив. N>Все что вы указали, по существу, это первое отличие. В абстрактном классе можно указывать реализацию в интерфейсе нет.
спор `java coders vs .net coders` разрешился как-то сам собой
Здравствуйте, -n1l-, Вы писали:
N>>нет, благодаря опыту N>Потрясающий ответ. N>- Почему этот старый мудрец такой мудрый? N>- Потому что он старый.
ну а что тут еще скажешь ? опыт — это опыт, он возникает из многолетнего решения разных задач, хождения по граблям, ковыряния в чужом коде — что-то здесь интересное увидел, что-то тут заметил и вот как-то так формируется опыт, это не те знания, которым можно научить в институте или научиться прочитав умную книжку
N>>я не понимаю, что такое "базовые знания", то что ты выше указал это ну максимум юниор какой-нить зеленый имеет право не знать N>Вообще под термином "базовые знания" должны подразумеваться алгоритмы и структуры данных и джун их должен знать прежде всего. Но предыдущий оратор явно имел ввиду какие-то специфические знания платформы.
Здравствуйте, -n1l-, Вы писали:
N>В абстрактном классе можно определить обычный метод с телом, что-то выполняющим и вызывать этот метод из наследника. N>Не обязательно каждый метод абстрактном классе помечать атрибутом abstract
я знаю что такое абстрактный класс, но интерфейс это вообще не класс, он совсем для других задач существует
Здравствуйте, Vzhyk, Вы писали:
V> 31.08.2013 0:52, Shmj пишет:
V> > Реально круто -- это знать в деталях высшую математику, эллиптическую V> > криптографию, знать тонкости алгоритмов и уметь изобретать свои новые V> > алгоритмы. Вот это реально мозг нужен. А выучить как сделали другие в V> > элементарщине -- фигня.
V> Может и круто, но спрос на нее маленький.
Маленький да удалеьнький: вон даже в Минске $5к вроде как предлагают за знания математики
Здравствуйте, cocacola, Вы писали:
C>Человек декомпилит код, и обьясняет чем asyn Task<TResult> отличается от async void под капотом. При этом он гик во Flash, С++ также.
Вот где собака порылась, в определённый момент при использовании Flash на серьёзном уровне (не картинку вставить) хочешь-не хочешь будешь всё это знать
Здравствуйте, devcoach, Вы писали:
D>На базовых знаниях все и строиться.
Ну то есть, если я знаю что такое кирпич то я могу автоматом строить дома? А небоскребы?
Знать базовые вещи нужно чтобы начать хоть что то делать: правильно или не правильно.
А положительный опыт уже дает больше шансов на успех что все будет сделано более менее правильно по куче параметров одновременно: эффективность, легкость в развитии, тестировании, развертываемости, интеграции с другими проэктами и так далее. А джуны как правило тонут в технических деталях и не видят за лесом деревьев.
Здравствуйте, Sash_xp, Вы писали:
S_>Мне кажется, это связано с задачами, которые в основном делают на C# — это все больше десктоп-приложения, либо интранет-сайты.
Это связано с тем, что С++ освоить очень сложно. Поэтому часть людей отсеивается. А те кто остаются вынуждены либо научиться аккуратно программировать, либо отлаживать всякие segmenation fault.
И те, кто не освоил С++ идут куда? Правильно в С#, в итоге средний уровень шарпистов сильно ниже. Хотя это и не исключает наличия там хороших специалистов, особенно в последнее время, когда С++ немного начал сдавать.
Здравствуйте, -n1l-, Вы писали:
N>Вот давайте не будем да? Мы с вами оба хорошо знаем, что хорошим спецам, действительно хорошим, язык безразличен.
Именно так. Но как правило есть один-два языка, которые у человека основные, ес ли это С++, то человека будут называть С++сником, не важно, что он ещё на lua может что-то сварганить.
Теперь берём хорошего спеца, для которого язык не важен. Какой у него будет основной язык? Скорее всего распределение будет совпадать с распределением использования языков. Если Java используют в 20% случаев, то среди хороших спецов 20% будут "Java"-программистами.
А теперь возьмём плохого программиста. Вероятность, что он будет писать на С++ достаточно низкая. В итоге распределение уже не будет повторять используемость языков, а сместится в сторону более простых.
В итоге получим, что среди С++ больше хороших программистов, чем среди шарпистов.
01.09.2013 22:23, Dziman пишет:
> Маленький да удалеьнький: вон даже в Минске $5к вроде как предлагают за > знания математики ))))))))))))))))))))))))))))
И понятно что из всего выпуска ФПМа, мехмата за несколько лет никто
математики не знает.
Писать надо потому что грамотно. Я выполнил инструкции в предложении так, как они были написаны. Нужно было уточнять.
Конечно в статическом классе нельзя объявить абстрактный метод. Почему?
Потому что он помечен определенным маркером virtual, т.е. его можено переопределять в наследниках, а так как в статическом классе наследования нет, то и не скомпилится ничего.
Туше мисье кот.
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, -n1l-, Вы писали:
A>Вот ты начал спорить с утверждением, что уровень дотнетчиков в среднем хуже, чем Java- или С++ программистов, а в итоге только подтверждаешь.
Чем? Тем что не соглашаюсь с мнением большинства о том, что интерфейс и абстрактный класс это принципиально разные вещи и у них множество отличий?
Или тем, что не так понял написанные мне очень умные доводы. Которые вообще не проверены.
Следите дальше за спорами, я вас не разочарую.
Здравствуйте, -n1l-, Вы писали:
N>Чем? Тем что не соглашаюсь с мнением большинства о том, что интерфейс и абстрактный класс это принципиально разные вещи и у них множество отличий?
Ты понимаешь разницу между интерфейсом и реализацией ?
Здравствуйте, devcoach, Вы писали:
D>3) Речь идет лишь о том, что C# это в бОльшей степени сайтики и декстоп, и в меньшей степени сложный server-side, и в еще меньшей степени еще более солжное системное программирование.
Т.е. то же самое, что и ява, но там еще и десктоп есть.
По вашей логике всех спецов из java должно бы вымыть и там сплошные умственные колеки должны бы остаться.
Здравствуйте, devcoach, Вы писали:
N>>Ну ладно, предположим, что специалисты программирующие на с++ все очень круты. N>>Но java? Java такой же фреймворк как и дотнет? Java то чем обходит? D>Вы шутите? Кроссплатформенность — слышали про такое7
Т.е. если завтра MS выпустит .net под линукс это автоматом магическим образом повысит "крутизну" всех дотнетчиков.
Здравствуйте, alzt, Вы писали:
A>А теперь возьмём плохого программиста. Вероятность, что он будет писать на С++ достаточно низкая. В итоге распределение уже не будет повторять используемость языков, а сместится в сторону более простых.
Интересует метод оценки такой вероятности.
A>В итоге получим, что среди С++ больше хороших программистов, чем среди шарпистов.
Итог этот выведен из очень неочевидного предположения.
Есть пример перед глазами. Государственное предприятие, в котором несколько сотен программистов перешли на C++ с фортрана и используют C++ на уровне фортрана. Ни о шаблонах, ни о спецификации и стандартах большая часть из этих программистов не слышали. Представьте, часть из них с трудом оперирует понятием "указатель".
И это им не мешает программировать на C++ и называться C++-никами. Я не написал "хорошо программировать". Акцент на "не мешает".
Они сидят себе на работе, на собеседования не ходят, книги и форумы на проф-темы не читают, про интернет слышали по телевизору, и не знают что кто-то C++ знает лучше чем они. Этот пример не о C++, эти люди с таким же успехом могли бы программировать на Java, просто C++ раньше попался под руку начальнику, который велел с фортрана на С++ перейти.
Здравствуйте, Yoriсk, Вы писали:
Y>Т.е. то же самое, что и ява, но там еще и десктоп есть. Y>По вашей логике всех спецов из java должно бы вымыть и там сплошные умственные колеки должны бы остаться.
Как вы пришли к такому забавному выводу? Я уже подробно описал, почему уровень джавистов выше уровня шарпистов.
Да, формально инструментарий что в Java, что в C# один в один. НО! Есть два важных отличия:
1) Где этот инструментарий можно использовать. C# намертво приварен к Windows (и не надо тут про Mono, который на данный абсолютно неприменим в промышленной среде, и будет таковым еще десяток лет как минимум). А Java может быть применена в любом окружении, в любой операционной системе. А все самые ответственные решения в большинстве своем крутятся в unix/linux средах, куда у C# путь закрыт.
2) Как следствие п.1, в мире Java для каждого спектра задач есть множество продуктов. Везде конкуренция. Следствие — более высокое качество, и возможность заменить непонравившейся инструмент на что-либо другое. В Windows такого нет. Есть политика партии, на которую надо ровняться.
Как следствие:
1) На Java можно решать гораздо больший спектр задач, включая очень сложные.
2) Уровень спецов на Java в среднем выше.
Ну а десктоп — это ерунда по сравнению с тем, что происходит на серверной стороне. Рисовать лэйауты и навешивать листенеры — много ума не надо.
Здравствуйте, Yoriсk, Вы писали:
Y>Т.е. если завтра MS выпустит .net под линукс это автоматом магическим образом повысит "крутизну" всех дотнетчиков.
Магическим образом ничего не произойдет. Если MS выпустит такой продукт, если на него клюнет бизнес, и захочет писать на нем сложный серверный софт, то со временем, лет за 5-7, уровень дотнетчиков обязательно подтянется.
Ведь почему у дотнетчиков низкий уровень? Потому что они "тупые"? Нет, просто умных задач под .Net исчезающе мало, все сайтики да формоклепство. Если появится спрос на высококлассную разработку — появится и предложение. Сейчас такого спроса почти нет.
Здравствуйте, devcoach, Вы писали:
D> и захочет писать на нем сложный серверный софт
Вы всю дорогу оперируете понятием "сложный серверный софт", не могли бы вы пояснить, что под этим понимаете и может быть пару примеров?
Здравствуйте, devcoach, Вы писали:
D>Здравствуйте, sharpcoder, Вы писали:
S>>Очень крутой программист от прошаренного мида отличается эффективностью работы, стабильностью кода, а главное — выбором наиболее подходящей для конкретной задачи архитектуры. D>Хахаха, то есть что вы сейчас сказали? Примерно следующее: "Крутой специалист круто потому, что он принимает правильные решения". А вы не хотите задуматься, за счет чего он принимает правильные решения? Совершенно верно — благодаря знанию базовых вещей.
Благодаря уму в первую очередь. Получить знания может любой, а вот пользоваться ими так, чтобы решать нестандартные задачи — это отличает высокого профессионала от "всезнайки". Я встречал людей который знают много но работают плохо, встречал тех кто знает меньше но работает очень эффективно.
Здравствуйте, dalmal, Вы писали:
D>Вы всю дорогу оперируете понятием "сложный серверный софт", не могли бы вы пояснить, что под этим понимаете и может быть пару примеров?
Amazon, eBay, Одноклассники, все критичные системы Deutsche Bank и Сбербанка.
Здравствуйте, nightcode, Вы писали:
N>Здравствуйте, bkat, Вы писали:
B>>Почему-то как только мы перешли от С++ на C# стало намного сложнее найти хороших спецов. B>>Вроде кандидатов больше, а вот выбирать почти не из чего... N>а мы вот перешли на scala, так это вообще караул — спецов просто нет, ни хороших, ни плохих, хоть обратно на яву возвращайся
Ну это предсказуемо.
У нас переход на C# мотивировался в том числе и тем, что типа спецов будет проще искать.
Фиг вам... Стало еще сложнее.
Раньше грубо говоря приходило пять резюме на вакансию, из которых три были интересными.
Сейчас приходит 20 и более из которых скрепя сердце выбираешь пару для дальнейшего разговора...
Хотя сейчас на С++ может вообще ни одного резюме не придет
Здравствуйте, devcoach, Вы писали:
D>Да, формально инструментарий что в Java, что в C# один в один. НО! Есть два важных отличия: D>1) Где этот инструментарий можно использовать. C# намертво приварен к Windows (и не надо тут про Mono, который на данный абсолютно неприменим в промышленной среде, и будет таковым еще десяток лет как минимум). А Java может быть применена в любом окружении, в любой операционной системе. А все самые ответственные решения в большинстве своем крутятся в unix/linux средах, куда у C# путь закрыт.
Вот статистика за прошлый год по доле серверных ОС от IDC (более свежей к сожалению не нашел):
Top Server Market Findings Linux server demand was positively impacted by high performance computing (HPC) and cloud infrastructure deployments, as hardware revenue improved 16.0% year over year in 1Q12 to $2.4 billion. Linux servers now represent 20.7% of all server revenue, up 3.3 points when compared with the first quarter of 2011. Microsoft Windows server demand was up 1.3% year over year in 1Q12 with quarterly server hardware revenue totaling $5.9 billion representing 50.2% of overall quarterly factory revenue, up 1.8 points over the prior year's quarter.
Unix servers experienced a revenue decline of 17.2% year over year to $2.2 billion representing 18.3% of quarterly server revenue for the quarter. IBM's Unix server revenue declined 3.7% year-over-year and gained 6.3 points of Unix server market share when compared with the first quarter of 2011.
The market for non-x86 servers, including servers based on RISC, EPIC (Itanium-based), and CISC processors, declined 16.1% year over year to $3.4 billion in 1Q12. This is the third consecutive quarter in which non-x86 servers have exhibited a revenue decline. Non-x86 based systems now comprise 28.5% of the server market, the lowest level ever reported in IDC's quarterly server tracker.
Как то кисло линукс побеждает. Что касается unix, то боюсь здесь и java и c# мимо цели (хотя я как то писал программу на mono к solaris, та еще жесть была).
Использовать java в windows — пустая трата времени и денег. 1) он совершенно непригоден для построения desktop-решений на win (нет норм. FCL для desktop) 2) он не имеет достойного web-каркаса в принципе (напр. аля ASP.Net MVC) + интеграции с IIS, что делает его крайне тяжеловесным.
Писать на java под OSX это вообще плохая идея. mono в этом отношении кстати гораздо быстрее и имеет больше tools в целом (для xamarin это бизнес, а для oracle OSX "еще одна unix").
Что касается "серверных решений", о которых вы талдычите, писать что на языке с GC без привязки к кернелл системы — это просто глупость. Кто будет пользоваться такими опасными с точки зрения производительности решениями?
D>2) Как следствие п.1, в мире Java для каждого спектра задач есть множество продуктов. Везде конкуренция. Следствие — более высокое качество, и возможность заменить непонравившейся инструмент на что-либо другое. В Windows такого нет. Есть политика партии, на которую надо ровняться.
Да нет "в мире Java" ничего. Есть только android apps. Это норм. ниша java, вот пожалуй и все.
Здравствуйте, devcoach, Вы писали:
D>>Вы всю дорогу оперируете понятием "сложный серверный софт", не могли бы вы пояснить, что под этим понимаете и может быть пару примеров? D>Amazon, eBay, Одноклассники, все критичные системы Deutsche Bank и Сбербанка.
Эээмм... Не слишком детальное описание. А поподробнее можно, если не затруднит? Что там такого запредельно сложного, может один-два примера?
Пока что вижу только всякие внутренние службы/сервисы банков и сайтики. Неужели это и есть "сложный серверный софт"?
Здравствуйте, -n1l-, Вы писали:
N>Вообще под термином "базовые знания" должны подразумеваться алгоритмы и структуры данных и джун их должен знать прежде всего. Но предыдущий оратор явно имел ввиду какие-то специфические знания платформы.
Для тебя "базовые знания" это "алгоритмы и структуры данных"?
Здравствуйте, dalmal, Вы писали:
D>Эээмм... Не слишком детальное описание. А поподробнее можно, если не затруднит? Что там такого запредельно сложного, может один-два примера? D>Пока что вижу только всякие внутренние службы/сервисы банков и сайтики. Неужели это и есть "сложный серверный софт"?
нет, сложный серверный софт это когда формочки натягиваются на таблички из базы, а это так херня для джунов
Здравствуйте, nightcode, Вы писали:
B>>Вроде кандидатов больше, а вот выбирать почти не из чего... N>а мы вот перешли на scala, так это вообще караул — спецов просто нет, ни хороших, ни плохих, хоть обратно на яву возвращайся
Судя по форумам, есть достаточно много мотивированных и высококвалифицированных людей, которые готовы даже с некоторым уменьшением зарплаты работать над каким-нибудь специфическим языком. Чаще всего этот язык является каким-нибудь функциональным, но и на скале многие хотят программировать.
Почему бы их не брать. Единственное но... опыта на скале у них скорее всего не будет.
Здравствуйте, nightcode, Вы писали:
N>нет, сложный серверный софт это когда формочки натягиваются на таблички из базы, а это так херня для джунов
Это понятно, а конструктивно есть что сказать? Что конкретно делает озвученные выше продукты "сложными"?
Здравствуйте, -n1l-, Вы писали:
N>Вы не можете знать какая доля хороших спецов пишет именно на с++, c#, java. N>Доля на рынке не показатель.
Не знаю, но могу делать выводы на основе наблюдений.
И скорее всего хорошие спецы будут работать там, где платят.
Здравствуйте, dalmal, Вы писали:
D>Здравствуйте, devcoach, Вы писали:
D>>>Вы всю дорогу оперируете понятием "сложный серверный софт", не могли бы вы пояснить, что под этим понимаете и может быть пару примеров? D>>Amazon, eBay, Одноклассники, все критичные системы Deutsche Bank и Сбербанка. D>Эээмм... Не слишком детальное описание. А поподробнее можно, если не затруднит? Что там такого запредельно сложного, может один-два примера? D>Пока что вижу только всякие внутренние службы/сервисы банков и сайтики. Неужели это и есть "сложный серверный софт"?
Здравствуйте, devcoach, Вы писали:
D>Как вы пришли к такому забавному выводу?
Это несложно. Я просто развил ваши мысли.
D>Я уже подробно описал, почему уровень джавистов выше уровня шарпистов.
А по вашим словам должен быть ниже. Ой.
D>А Java может быть применена в любом окружении, в любой операционной системе. А все самые ответственные решения в большинстве своем крутятся в unix/linux средах, куда у C# путь закрыт.
Тут есть три момента:
1) Не совсем очевидно, что все ответственные решения на линукс.
2) Не совсем очевидно, что все ответственные решения на линукс принимаются в пользу Явы.
3) Не совсем очевидно, что все ответственные решения на линукс, принятые в пользу Явы как-то отражаются на многомилионной армии явистов, пилящих опердень и сайтик на jsp.
D>2) Уровень спецов на Java в среднем выше.
В чём? Уровень каких спецов? В Бангалоре?
D>На Java можно решать гораздо больший спектр задач, включая очень сложные.
Каких сложных? Какие-то числодробилки и мегаоптимизации? Так вся ваша кроссплатформенность идёт в лесом и вообще зачем там Ява. А если нет — то в чём отличие от того же .net?
D>Ну а десктоп — это ерунда по сравнению с тем, что происходит на серверной стороне. Рисовать лэйауты и навешивать листенеры — много ума не надо.
Гы... Где же тот топик, где фронтенщики уверяли, что сервер — это полнейшая ерунда, заполнить энтити и Энтити.СабмитЧенджез() может любая обезьяна. А вот грамотно спроектированое дерево контролов, общающихся через ИвентБас — это да...
Здравствуйте, devcoach, Вы писали:
D>Вы прежде чем называть Amazon "сайтиком", почитайте лучше про его архитектуру — http://highscalability.com/amazon-architecture , а то за дурака в приличном обществе примут.
Ява там упоминается аж один раз, причём весьма невнятно:
• Not stuck with one particular approach. Some places they use jboss/java, but they use only servlets, not the rest of the J2EE stack.
• C++ is uses to process requests. Perl/Mason is used to build content.
С++ для бизнеслогики, Перл — для парсинга... А Ява что делает? Какие-то внутренние утилиты?
Смотрите, как интересно. То есть, судя по вашей интерпретации данных цифр, все сидят на Виндах, а Java никто не использует. При этом:
1) Потребность в Java программистах лишь немного ниже потребности в .Net
2) Джависты зарабатывают больше
Как же так, как же так? То есть вы, такой умный, понимаете, что Java вообще в полной заднице, при этом на самом деле Java в абсолютных числах востребована так же, как и C#, да еще и оплачивается лучше. Может быть, в ваши рассуждения закрклась ошибка?
Ну конечно закралась! И не ошибка, а ошибище! Ведь, во-первых, вы учли только количественные показатели, но проигнорировали количественные. Конечно, шарпистов нужно больше, так как спрос на сайты-визитки, где рулит .Net, многократно превышает спрос на server-side, где рулит Java. И так везде — рабочих нужно много, а прорабов меньше. Чем ниже уровень соискателя, тем больше спрос. Один программист Java из Amazon стоит дасятка формоклепателей из .Net. Во-вторых, вы исходите из неверноего предположения, что на платформах Microsoft используют только .Net, что разумеется ошибочно. Вы так думаете, потому что для вас "разработка" — это формо- и сайтоклепательство. А для меня "разработка" — это и формоклепательство, и server-side, и энтерпрайзные standalone решения, и прочее, и прочее.
Здравствуйте, Yoriсk, Вы писали:
Y>Ява там упоминается аж один раз, причём весьма невнятно: Y>
Y>• Not stuck with one particular approach. Some places they use jboss/java, but they use only servlets, not the rest of the J2EE stack.
Y>• C++ is uses to process requests. Perl/Mason is used to build content.
Y>С++ для бизнеслогики, Перл — для парсинга... А Ява что делает? Какие-то внутренние утилиты?
Коллега, вы за нитью разговора вообще следите?
Прошлую ссылку я дал для того, что бы показать, что это за такой "сайтик" под названием Amazon, а не для того, что бы выискивать там слово "java". Если вам интересно, где именно в Амазоне используют java, то загляните на их сайт: http://www.amazon.com/gp/jobs/ref=j_sq_btn?jobSearchKeywords=java&category=*&location=*&x=-1819&y=-166
Как видите, джавистов там надо очень много, и занимаются они там отнюдь на второстепенными вещами. Потом для сравнения посмотрите, сколько им требуется плюсовиков и перловиков — в разы меньше.
Здравствуйте, dalmal, Вы писали:
D>Это понятно, а конструктивно есть что сказать? Что конкретно делает озвученные выше продукты "сложными"?
высокие нагрузки, big data, резервирование всякое и пр., т.е. ситуация когда нельзя тупо взять сервак помощнее
Здравствуйте, nightcode, Вы писали:
N>высокие нагрузки, big data, резервирование всякое и пр., т.е. ситуация когда нельзя тупо взять сервак помощнее
Ну так этого добра и на .NET'е хватает
Здравствуйте, devcoach, Вы писали:
D>Потом для сравнения посмотрите, сколько им требуется плюсовиков и перловиков — в разы меньше.
Ну так оно и понятно. Серьёзный сервер-сайд на плюсах, там работа не для всех, основательные знания нужны, а прикладные утилитки на java, их нужно куда больше количество.
Здравствуйте, devcoach, Вы писали:
D>Вы прежде чем называть Amazon "сайтиком", почитайте лучше про его архитектуру — http://highscalability.com/amazon-architecture , а то за дурака в приличном обществе примут.
А Stackoverflow разве не на .NET написан?
Здравствуйте, dalmal, Вы писали:
D>Здравствуйте, devcoach, Вы писали:
D>>Потом для сравнения посмотрите, сколько им требуется плюсовиков и перловиков — в разы меньше. D>Ну так оно и понятно. Серьёзный сервер-сайд на плюсах, там работа не для всех, основательные знания нужны, а прикладные утилитки на java, их нужно куда больше количество.
А вы умеете вырвать одно предложение из контекста, деликатно умолчав о другом. Зачет. Действительно, джависты в Амахоне разрабатывают всякую фигню. Например, S3 — http://www.amazon.com/gp/jobs/213318/ref=j_sr_35_t?ie=UTF8&category=&jobSearchKeywords=java&location=&page=2
Здравствуйте, devcoach, Вы писали:
D>А вы умеете вырвать одно предложение из контекста, деликатно умолчав о другом.
Да, я спец в этом, спасибо!
Ну короче мы как делаем? Открываем hh.ru смотрим количество вакансий для джавистов. В среднем, их количество в три раза больше, чем для для дотнета. Правильно? Правильно. Процентов 10 — что-то интересное. Всё остальное — отстой, формошлепство и так далее. Соответственно средний уровень этих 90% джавистов — удручающе низок, потому что они занимаются такими проектами. То же самое с дотнетом. 10% — интересные проекты, остальное — скучно и просто.
Что в итоге имеем? Что количественно слабых джавистов большем, чем слабых дотнетчиков. В процентном соотношение — одинаково. Так-то.
Здравствуйте, dalmal, Вы писали:
D>А Stackoverflow разве не на .NET написан?
На .Net, так же, как и myspace. Исключения, который лишь подтверждают правило.
Здравствуйте, devcoach, Вы писали:
D>>А Stackoverflow разве не на .NET написан? D>На .Net, так же, как и myspace. Исключения, который лишь подтверждают правило.
Твои примеры ровно такие же исключения.
Впрочем выше уже изложил своё видение ситуации, мне теперь скучно, до свидания.
Здравствуйте, dalmal, Вы писали:
N>>высокие нагрузки, big data, резервирование всякое и пр., т.е. ситуация когда нельзя тупо взять сервак помощнее D>Ну так этого добра и на .NET'е хватает
ну вообще я прицепился к твоей фразе про "а что там такого сложного ?", то что на .NET нельзя делать проект под высокую нагрузку я не утверждал. Правда на для java, imho, "добра" все же побольше будет
Здравствуйте, Shmj, Вы писали: S>От задротства большой толк. Это, можно сказать, одно из важных в 90% проектах. Не всем изобретать новые алгоритмы, для большинства достаточно уметь использовать то, что придумали умные дядьки.
с задротами проблема, что с ними каши не сваришь. их много по жизни унижали, а, значит, они сами, получив малейшую власть начинают отыгрываться на остальных. да и по жизни с ними скучно говорить — кроме гномикам, async и хентая они больше ничем не интересуются
Здравствуйте, -n1l-, Вы писали:
N>>Ты понимаешь разницу между интерфейсом и реализацией ? N>Да, а вы?
Ну, во первых на "вы" это тут не принято, а во вторых как тогда понимать эту фразу:
Тем что не соглашаюсь с мнением большинства о том, что интерфейс и абстрактный класс это принципиально разные вещи и у них множество отличий
Это действительно принципиально разные вещи и у них больше разного, чем общего. И свойства у них совсем разные.
Да, если взять строго ограниченную ситуацию, когда в абстрактом классе будут одни только абстрактные методы, не будет полей и его потомки будут наследовать только один этот класс, то видимой разницы с интерфейсом не будет
Но это, как бы, достаточно искуственная ситуация
Здравствуйте, nightcode, Вы писали:
N>Здравствуйте, -n1l-, Вы писали:
N>>>Ты понимаешь разницу между интерфейсом и реализацией ? N>>Да, а вы? N>Ну, во первых на "вы" это тут не принято, а во вторых как тогда понимать эту фразу:
Это у вас, "вы" не принято. Я к незнакомым мне людям обращаюсь на вы.
N>Это действительно принципиально разные вещи и у них больше разного, чем общего. И свойства у них совсем разные.
Все в чем заключается эта разность между интерфейсом/абстрактным классом — отсутствие/наличие реализации.
Здравствуйте, -n1l-, Вы писали:
N>Это у вас, "вы" не принято. Я к незнакомым мне людям обращаюсь на вы.
у "нас" это здесь, на rsdn
N>>Это действительно принципиально разные вещи и у них больше разного, чем общего. И свойства у них совсем разные. N>Все в чем заключается эта разность между интерфейсом/абстрактным классом — отсутствие/наличие реализации.
ага, такая непринципиальная мелочь и то что класс может реализовывать несколько интерфейсов, но наследовать может только один класс это тоже непринципиальная фигня
я же говорю, сходство в использовании можно уловить в искуственном, ограниченном примере, который ты вырезал из предыдущего сообщения
Здравствуйте, nightcode, Вы писали:
N>ага, такая непринципиальная мелочь и то что класс может реализовывать несколько интерфейсов, но наследовать может только один класс это тоже непринципиальная фигня
Это дополнение c#(конкретная реализация), но не абстрактного класса или интерфейсов.
N>я же говорю, сходство в использовании можно уловить в искуственном, ограниченном примере, который ты вырезал из предыдущего сообщения
А что если вы загляните под капот скомпилированного интерфейса и увидите вот это:
interface IC
{
void GetVal();
}
.class interface private abstract auto ansi SomeNewApp.IC
{
} // end of class SomeNewApp.IC
Что мне сейчас мешает назвать интерфейс классом? Ничего. Так же как мне ничего не мешает назвать статический класс абстрактным с блокированным наследованием.
Но я так не делаю, потому что это есть конкретная реализация.
В конкретной реализации абстрактного класса и интерфейсов или просто класса, может быть все что угодно. Например в ruby класс — внезапно метод.
Самое главное отличие это наличие или отсутствие реализации(и по идее единственное).
В интерфейс, что бы вы ни делали и как бы вы его не проектировали не должна попадать никакая реализация никаких методов классов использующих(реализующих)этот интерфейс.
В абстрактном классе такая реализация может присутствовать.
Здравствуйте, cocacola, Вы писали:
C>Часто читал что мол позор на фирмах, никто не знает чем абстрактный класс от интерфейса отличается. C>У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу.
Значит повезло с текущим местом работы вам. набирайтесь опыта, а потом идите в фирму, где гиков нет — будете там сеньером, или тимом.
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>По заслугам... Выставление уровня по времени считаю бредятиной...
По каким еще заслугам? Вот пришел новый человек в команду и нету у него еще никаких заслуг, а иботеки и кредиты есть. Или ему каждый раз начинать с джунской зарплаты чтобы доказать что он не лось?
Здравствуйте, Grizzli, Вы писали:
G>Здравствуйте, cocacola, Вы писали:
C>>Часто читал что мол позор на фирмах, никто не знает чем абстрактный класс от интерфейса отличается. C>>У нас 100% такого нет, реально много гиков. Причем зп средняя довольно по городу.
G>Значит повезло с текущим местом работы вам. набирайтесь опыта, а потом идите в фирму, где гиков нет — будете там сеньером, или тимом.
И как он будет решать проблемы? Если заказчики озвучивают свои проблемы не в виде списка классов на C#, а на уровне запретите посетителям делать скриншоты нашего сайта.
Здравствуйте, cocacola, Вы писали:
> Как у вас с этим на работе? Какой уровень ваших коллег?
А у нас в квартире газ коллеги такие:
* человек заметил, что какой-то тест валится в его конфигурации билда. Он сразу баг мне пишет, мол ты этим кодом занимаешься, ты и разбирайся. Никакой дополнительной информации, как воспроизвести, лог, там можно было бы и покопаться немного если уж наткнулся на баг. Нифига. И вроде в одной команде работаем, над одним кодом.
* есть допустим какая-то нетривиальная проблема, которую нашли люди из другой группы, использующие наш код. Баг создан, repro есть, всё такое. Несколько человек из нашей группы сразу начинают предлагать решения — "а может это то, или может это?". Ни один из них даже не попробовал воспроизвести баг, под отладчиком прогнать. Лишь бы что-нибудь пёрнуть в баге, чтобы все видели, какие они умные. Когда начнёшь изучать проблему, причина оказывается, конечно, совершенно в другом.
* если пытаешься помочь человеку с его проблемой, то он вместо того, чтобы сделать то, что ты ему предлагаешь, сразу хочет повесить её на тебя. Инициатива наказуема!
* фичи предлагаются офигенные иногда. И чем дибильнее фича, тем больше человек её стараются поддержать. Причём я почти уверен, что большинство даже не понимает о чём идёт речь. А когда доходит дело до реализации, все почему-то сразу теряют интерес. Но если им сказать, что эта *?:#(%* не будет работать, и вообще такой проблемы нет, которую они хотят решить, то ты сразу главный враг, и ничего совсем не понимаешь в этом деле.
* когда сделаешь большой кусок работы, нужно в порядке вещей, чтобы кто-то сделал code review. Но вместо замечаний по существу получаешь что-то вроде: "вот здесь из одного класса надо сделать два, а здесь из двух — один", запятые и скобочки не на тех строчках поставил и не выравнил параметры функций, подлец! В итоге получается по результатам code review куча работы по переливанию из пустого в порожнее.
* если же наоборот, что стараешься дать коллеге feedback по существу по его коду, то тут начинается цирк с увиливаниями и поиском отговорок, почему так сделать нет никакой возможности.
Здравствуйте, Antidote, Вы писали:
A>Здравствуйте, uncommon, Вы писали:
U>>Вот такие пироги. Всё относительно.
A>С кем поведёшься — так тебе и надо Может, вам пора менять работу
Здравствуйте, -n1l-, Вы писали:
N>Самое главное отличие это наличие или отсутствие реализации(и по идее единственное). N>В интерфейс, что бы вы ни делали и как бы вы его не проектировали не должна попадать никакая реализация никаких методов классов использующих(реализующих)этот интерфейс. N>В абстрактном классе такая реализация может присутствовать.
имхо главное отличие это отсутствие состояния у интерфейса, тк реализация по умолчанию может быть.
