Здравствуйте, 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%.

Здравствуйте, devcoach, Вы писали:

Ок, ну все понятно. Давайте абстрогируемся. Представим, что вы специалист c++, который работает с ком портом считывая с него данные. Данные приходят к вам в виде массива из десятичных чисел типа byte. Далее вы проводите какие-то обычные арифметические операции типа умножения и деления и отсылаете результат в файл.
Я — программист которые эту же задачу решает на асме, но в отличии от вас, предположим мне нужно все эти арифметические операции реализовать. Т.е. у меня задача та же самая, но реализация "ниже" как вы выразились.
А теперь вопрос, могу ли я сказать, что вы как специалист хуже чем я, раз я решаю задачу на языке в котором меньше возможностей?
Второй вопрос, что вам мешает понимать, как работает арифметика компьютера программируя на более высокоуровневом языке.
Еще раз сделаю акцент на вашей логике.
Вы берете разработчика, который пишет в основном сайты на asp.net и начинаете принижать его компетенцию за то, что он не писал каких-то сложных абстрактных серверов и систем. Позже вы эти выводы обобщаете на всех.
Я вот например, абсолютно уверен в том, что программируя на с++ можно вообще не знать как работает программный стек.
Другое дело, что я бы не использовал с++ если бы мне не была критически важна производительность.

Ну ладно, предположим, что специалисты программирующие на с++ все очень круты.
Но java? Java такой же фреймворк как и дотнет? Java то чем обходит?

D>Это как раз то, о чем идет речь в топике.
Мы как бы отошли от контекста топика, если что.

    abstract class A
    {
        
    }

    static class B
    {
        
    }

.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>Ну так назовите.
Пожалуйста. У объявлений в классе можно указывать модификатор видимости. У интерфейса — нет.
Или вам все отличия указать? Боюсь,что я не подписывался. Еще раз. Я лишь опроверг ваш тезис о том что "Все" после одного отличия.

Здравствуйте, -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>

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 просто не имеет соответствующей специфики для представления статических классов. Вы бы еще в машинных кодах разницу поискали.
Угу. Если следовать его логике, то локальные переменные, попавшие в лямбду, надо называть полями класса.