Здравствуйте, lomeo, Вы писали:
L>При чем тут твой список? Где ты сказал, что то, что С# классический ОО, это твоё мнение?
При том, что это мое мнение. Твои проблемы соглашаться с ним или нет. Не согласен, можешь попробовать доказать обратное. Но я не обязан каждому встречному давать исчерпывающие обоснования. Тут море фанатов. Находятся фанаты любой экзотики. И если каждому объяснять почему не упомянули его любимую игршку, то жинь пройдет.
L>Указывать другим на то, что им делать — это запросто.
Указывай. Только отдельной веткой. Я, если не соглашусь поставлю тебе минус.
L> Наплести логически несвязанного винегрета — пожалуйста!
Плети. Кто же против то?
L> Но как только ты слышишь мнение отличное от своего, то сразу поднимается оскорбленный вопль о списках, находящихся в частной собственности. Очень по детски.
Ты явно что-то не понимаешь. Мне плевать на твое мнение. Я просто не хочу провести неделю в оправданиях. Я шел 15 лет к тому чтобы сформировать это мнение и не хочу от него отказываться. По крайней мере без весомых на то причин. Вокруг много крикунов неспособных сказать ничего интересного, но каждый из них с радостью докопается до любых слов и начент развивать почему его любимую игрушку не включили в список.
Ответ простой — не считаю нужным.
VD>>Еще раз. Создай отдельно свой список и хоть Перл туда запиши. Мой списко трогать не надо.
L>Правила форума это запрещают?
Нет. А тебя сдерживают от глупых поступков только правила форума?
L>Термин я знаю. Ок, обратимся к Википедии.
Значит я его не выдумал? ОК, так и запишем — ты погорячился.
L>
L>Prototype-based programming is a style of object-oriented programming in which classes are not present, and behaviour reuse (known as inheritance in class-based languages) is accomplished through a process of cloning existing objects which serve as prototypes.
L>Я, наверное, что то путаю, но в Смолтолке есть и классы и переиспользование там достигается совсем другими механизмами.
Смолток позволяет вмешиваться в структуру объектов в рантайме. Это свойства тех самых прототипных языков. Смолтон не чистный прототипный язык. Но он был преттече Сэлфа. Идеи Сэлфа почерпнуты именно из природы Смолтока.
В общем-то Руби развивает эту идеяю в полной мере и, на мой взгляд, более красиво. Хотя сама идея менять объекты в рантайме мне категорически не нравится.
L>Так что ты опять что то изобрел. Я и спрашиваю — что?
Ты это утверждаешь, тебе и доказывать. Не буду же я доказываь или опровергать каждую твою фантазию?
VD>>А мне по барабуну ты лично и то что ты думаешь о моей логие в частности.
L>Зачем тогда ты это пишешь?
Ты серьезно считашь, что я это делал специально для тебя?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
1. Разговор в стиле меряний длины органов у нас явно не получится: возможно, вам такой вариант нравится, но мне нет. Мы или говорим четко по теме, или вы скатываетесь в обсуждение своего величия и ущербности ваших собеседников? Второй вариант клоунады неинтересен.
2. Про знание языков все же отвечу. Да, опыта на Java больше: около 3 лет, на .NET же разработки веду уже второй год, при этом продолжаю "свободные" проекты писать на Java. Разумеется, и это не все ЯП, с которыми приходилось иметь дело. Про уровень своего профессионализма говорить считаю неуместным и смешным делом (хватит и того, что вы написали), тем, чем настоящий профессионал, как мне кажется, никогда заниматься не станет.
3. Подробно комментировать глупые нападки не имею желания. Одно только, статью, ссылку на которую дал dshe (As vs Cast), читал, и достаточно давно, честно говоря, воспринял ее тогда с долей юмора: история о том, как вначале C# предоставляет свободу действий, расчитывая на то, что имеет дело с профессионалом, а потом... когда приходит понимание, что программисты — тоже люди, которым свойствено ошибаться, пишутся разгромные научные труды, как же побороть ошибки от необдуманного своеволия в C#.
4. Если правильно расставить акценты, то разговор начался с того, что C# был объявлен классикой ООП, а Java послали в лес. У меня вовсе не было желания все сделать наоборот: C# послать в лес, а Java восхвалить — эти священные войны все же детство, а работать все равно приходится с обоими платформами. Речь же "зачиналась" о конкретных недостатках каждого из языков — вот это было бы интересно обсудить.
VD>Мой не трогай.
Забавно.
Здравствуйте, VladD2, Вы писали:
VD>Ты явно что-то не понимаешь. Мне плевать на твое мнение. Я просто не хочу провести неделю в оправданиях. Я шел 15 лет к тому чтобы сформировать это мнение и не хочу от него отказываться. По крайней мере без весомых на то причин. Вокруг много крикунов неспособных сказать ничего интересного, но каждый из них с радостью докопается до любых слов и начент развивать почему его любимую игрушку не включили в список.
Это ты явно чего то не понимаешь, что ты там включил или не включил в свой список мне пофиг. Что ты носишься с ним, ей-богу не понимаю
VD>>>Еще раз. Создай отдельно свой список и хоть Перл туда запиши. Мой списко трогать не надо.
L>>Правила форума это запрещают?
VD>Нет. А тебя сдерживают от глупых поступков только правила форума?
Ну, тебя то они не сдерживают.
Моё замечание о Смолтолке стоит расценивать исключительно как предложение для дополнительного изучения. Оно находилось в ответе на твой пост в связи со сравнением с ОО языками. Ты зря думаешь, что я как то хочу задеть твой список. О Смолтолке -- это не к тебе, это к спросившему. Жаль, что это так сильно тебя зацепило.
L>>Термин я знаю. Ок, обратимся к Википедии.
VD>Значит я его не выдумал? ОК, так и запишем — ты погорячился.
"Согласно постулатам логики Влада" :-)
Я говорил о "новых определениях старых терминов" ;-)
VD>Смолток позволяет вмешиваться в структуру объектов в рантайме. Это свойства тех самых прототипных языков. Смолтон не чистный прототипный язык. Но он был преттече Сэлфа. Идеи Сэлфа почерпнуты именно из природы Смолтока.
Елки. Смолтолк позволяет в рантайме менять классы, а не объекты, ну добавишь ты каждому объекту класса А по полю... да и вообще это никаким боком к прототипным языкам. Смолтолк не то что не чистый прототипный язык, он вообще не прототипный язык. Для прототипного языка как минимум необходима возможность порождения от прототипа нового объекта с возможностью изменения его поведения.
VD>>>А мне по барабуну ты лично и то что ты думаешь о моей логие в частности.
L>>Зачем тогда ты это пишешь?
VD>Ты серьезно считашь, что я это делал специально для тебя?
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Грязь и бедность — это не одно и то же однако. То что ты привёл — это бедность в выразительных средствах. Грязь (то есть именно непоследовательность и обилие граблей) в Jave конечно есть, я бы туда отнёс некрасивую работу с плоскими типами (особенно когда туда приплели автобоксинг в 5-й джаве).
ИМХО, (ИМХО!) главная грязь Java заключена в крайне запутанной концепции inner classes. Ну и в вытекающей из этого грязности (грязноте?) анонимных классов.
Здравствуйте, fmiracle, Вы писали:
L>>А основы электроники-то зачем?
F>Думаю — для общего развития. Представлять себе как примерно функционирует компьютер
На электрическом уровне? А зачем? И, что забавно, ПТЦА было вобще не упомянута, хотя она то точно будет полезна, если уж гнаться за кругозором.
AndrewVK wrote: > ИМХО, (ИМХО!) главная грязь Java заключена в крайне запутанной концепции > inner classes. Ну и в вытекающей из этого грязности (грязноте?) > анонимных классов.
Кхм. А что в них такого запутанного? Все ясно и понятно — это просто
(почти) синтаксический сахар.
Там из несинтаксического сахара только один хак в верификаторе.
Здравствуйте, Cyberax, Вы писали:
C>Кхм. А что в них такого запутанного?
Нелогично. Из разряда "понять нельзя, можно только запомнить". Нет, я конечно понимаю, что если поглубже закопаться в проблемы языка и VM, то понять причины такого варианта можно, но, ИМХО, для основополагающих концепций языка это слабая отговорка. Такие концепции должны быть кристалльно прозрачны без наличия каких то специфичных знаний и сложной логики. Если не получается, то лучше такую конструкцию выкинуть и заменить другой, решающей сходные проблемы другим способом.
C> Все ясно и понятно — это просто C>(почти) синтаксический сахар.
Увы нет. Вот в шарпе это дейтвительно понятно (ну, если не брать некоторые тонкости, связанные с дженериками), поскольку это (за исключением контроля доступа) синтаксический сахар. А вот в Java все намного печальнее. Там есть разновидности, которые остаются inner классами и в рантайме со всеми вытекающими. И вот взаимодействие экземпляров этих классов с экземпляром класса владельца это весьма хитрая конструкция.
C>Там из несинтаксического сахара только один хак в верификаторе.
AndrewVK wrote: > C>Кхм. А что в них такого запутанного? > Нелогично. Из разряда "понять нельзя, можно только запомнить".
Мне хватило 10 минут, чтобы понять как оно работает — когда я
декомпилировал их и посмотрел что там внутри. Все сразу становится ясно.
> конечно понимаю, что если поглубже закопаться в проблемы языка и VM, то > понять причины такого варианта можно, но, ИМХО, для основополагающих > концепций языка это слабая отговорка. Такие концепции должны быть > кристалльно прозрачны без наличия каких то специфичных знаний и сложной > логики. Если не получается, то лучше такую конструкцию выкинуть и > заменить другой, решающей сходные проблемы другим способом.
Ты можешь привести пример "непрозрачности"?
> C> Все ясно и понятно — это просто > C>(почти) синтаксический сахар. > Увы нет. Вот в шарпе это дейтвительно понятно (ну, если не брать > некоторые тонкости, связанные с дженериками), поскольку это (за > исключением контроля доступа) синтаксический сахар.
В Java это именно сахар. Ну почти сахар — есть несколько методов в
классе Class для работы с вложенными классами.
> намного печальнее. Там есть разновидности, которые остаются inner > классами и в рантайме со всеми вытекающими. И вот взаимодействие > экземпляров этих классов с экземпляром класса владельца это весьма > хитрая конструкция.
Обычные прокси-методы. Что тут такого?
> C>Там из несинтаксического сахара только один хак в верификаторе. > Ты это, с шарпом не попутал?
Нет. Там есть хак, который позволяет в конструкторах inner-классов иметь
код ДО вызова super-конструктора. Как раз для того, чтобы
инициализировать прокси.
Здравствуйте, Cyberax, Вы писали:
>> C>Кхм. А что в них такого запутанного? >> Нелогично. Из разряда "понять нельзя, можно только запомнить". C>Мне хватило 10 минут, чтобы понять как оно работает — когда я C>декомпилировал их и посмотрел что там внутри. Все сразу становится ясно.
Ключевой момент я пометил жирным. ИМХО, это неприемлемо для понимания концепций языка.
C>Ты можешь привести пример "непрозрачности"?
Что значит пример? Inner classes и их взаимодействие с outer class, особенно когда речь заходит об экземплярах и есть такой пример.
>> намного печальнее. Там есть разновидности, которые остаются inner >> классами и в рантайме со всеми вытекающими. И вот взаимодействие >> экземпляров этих классов с экземпляром класса владельца это весьма >> хитрая конструкция. C>Обычные прокси-методы. Что тут такого?
Нет там в языке никаких прокси-методов. Ты вот смотри что постоянно делаешь — как только пытаешься объяснить почему сделано так и не иначе, так тут же скатываешься на детали реализации. Именно об это я и говорю.
AndrewVK wrote: >> > C>Кхм. А что в них такого запутанного? >> > Нелогично. Из разряда "понять нельзя, можно только запомнить". > C>Мне хватило 10 минут, чтобы понять как оно работает — *когда я* > C>*декомпилировал их и посмотрел что там внутри*. Все сразу становится ясно. > Ключевой момент я пометил жирным. ИМХО, это неприемлемо для понимания > *концепций языка*.
Можно было бы в tutorial'е по языку просто написать, что такая
конструкция просто аналогична другой. Вот и все.
> C>Ты можешь привести пример "непрозрачности"? > Что значит пример? Inner classes и их взаимодействие с outer class, > особенно когда речь заходит об экземплярах и есть такой пример.
Inner-класс имеет доступ к переменным экземпляра outer-класса и к
final-переменным того метода, в котором он был создан (если он был
создан внутри метода). Что тут сложного?
Здравствуйте, Cyberax, Вы писали:
C>Можно было бы в tutorial'е по языку просто написать, что такая C>конструкция просто аналогична другой. Вот и все.
Это и называется нельзя понять, можно только запомнить.
C>Inner-класс имеет доступ к переменным экземпляра outer-класса и к C>final-переменным того метода, в котором он был создан (если он был C>создан внутри метода). Что тут сложного?
Здравствуйте, AndrewVK, Вы писали:
AVK>И, что забавно, ПТЦА было вобще не упомянута, хотя она то точно будет полезна, если уж гнаться за кругозором.
Да, согласен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Last Cjow Rhrr, Вы писали:
LCR>Грязь и бедность — это не одно и то же однако. То что ты привёл — это бедность в выразительных средствах.
Нет, это как раз грязь. Грязь это когда язык содержит грабли которых можно было бы избежать. Грязь — это когда он непродуман.
LCR> Грязь (то есть именно непоследовательность и обилие граблей) в Jave конечно есть, я бы туда отнёс некрасивую работу с плоскими типами (особенно когда туда приплели автобоксинг в 5-й джаве).
Не знаю что плохого в автобоксинге, без него было куда хуже. Соглашусь, что если бы разницы между вэлью-типами и ссылочными типами небыло, то было бы уроще. Но без супер-оптимизаций компилятора это привело бы к серьезному замедлению выполнения множества приложений. Собственно Смолток это замечательно показал. Ни один ХотСпот его не спас. А Ява очень даже шутсро бегает. Дотнет и подавно.
LCR>synchronized методы — это взведённые грабли, ждущие когда на них наступят.
Вот это вообще заблуждение. Это не большие грабли чем возможность создать публичное поле. Позволяет нарушать инкапсуляцию — да, но это можно сделать сотней других способов.
А многопоточность в Яве вообще не продумана. Ввели какие-то примитивы (да еще и через зад), но толку от этого == 0. Писать многопоточный софт так же трудно как на С++. Тут нужны другие решения: 1) автоматическое распараллеливание, 2) аналог системы сообщений Эрлэнга. Вот это дало бы толк. А ручная синхнонизация крути, не крути все равно приведет к ошибкам которые будет трудно найти.
LCR>проваливающийся switch/case.
Согласен.
LCR>Редкие, но грабли.
У когда как. Да и редкая проблема может остановить проект лучше частой. Ведь к частым привыкают.
LCR>
LCR>char d = '9' - '0'; // ашыпка
LCR>
LCR>Если есть байтовое значение, большее 127 и к нему прибавить другое значение, то получаем не то что ожидали. Нужно сначала преобразовать значения к интам, потом уже производить арифметику. LCR>
+1
LCR>List<String>[] data = new ArrayList<String>[10]; // такие коллекции недопустимы
LCR>List<String> data1 = new ArrayList<String>(); // а так мона
LCR>
LCR>Если разобраться, конечно понятно почему, но тем не менее непоследовательно это. Либо запрещать ковариантность для всех коллекций, либо обеспечивать.
Незнал. Действительно задница. И разбираться тут смысл нет. Она от этого не пропадет. В Шарпе это нормальный код.
Что за проблема не дает создать массив ArrayList-ов?
В общем, как я уже сказал, таких проблем море. Их описание может занять много времени и естественно все фанаты Явы скажут что это все фигня, и так и надо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aquila, Вы писали:
TI>>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
ЗХ>>Однозначно последнее.
A>Многозначно сомневаюсь.
А откуда берутся сомнения? Изучать новый язык просто так? Даже несмотря на то что сейчас он не нужен? Из логики "Может быть пригодиться"? (с). Это и есть пустая трата времени. Это самое время можно потратить более продуктивно. Имхо, конечно.
L>А откуда берутся сомнения? Изучать новый язык просто так? Даже несмотря на то что сейчас он не нужен? Из логики "Может быть пригодиться"? (с). Это и есть пустая трата времени. Это самое время можно потратить более продуктивно. Имхо, конечно.
видишь ли, в чём прикол — мы все используем наши языки не совсем по назначению, вносим в них те концепции (паттерны программирования), которые изначально в языке отсутствуют. используем продцедурное программирование с ассемблером, ООП — с Си, функциональное — с С++. и для того, чтобы знать, как можно улучшить свои паттерны программирования, и полезно знать другие языки. кроме того, некоторые сами выбирают, на чём им писать
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Timur I., Вы писали:
TI>>Как считаете, стоит ли тратить время на изучения "альтернативных" языков и технологий ? Под альтернативными я понимаю не C++/Java/Php/Perl/C# Или это будет пустая трата времени и сил ?
VD>Мой список языков котрый может расширить кругозор: VD>1. C# — классика ООП, компонентность, статическая типизация, обобщенное программирование. VD>2. Руби — классика скриптов, динамика, гибкость. VD>3. Хаскель — функциональный подход, вывод типов, красивая идея классов типов (похожая на интерфейсы в C#, но которые можно подключать к уже имеющися типам), ленивое исполнение. VD>4. XQuary/XSLT — как пример языков трансформации данных. VD>5. Схема — как пример языка без синтаксиса и мощи макросов. VD>6. Рад, что даждались ожидаемого. Правильно немерле как квинтесенция свсего перечисленного выше. VD>7. Пролог, как демонстрация красивой идеии логического программирования практичски бесполеной на прктие. VD>8. SQL — пример декларативного языка обраобтки данных. VD>9. Регулярные выражения и Перл, как пример того что и на системах фирования можно писать программы.
Добавил бы еще
Eiffel — за "все объект", понятия контрактов, систему множественного наследования, четкую и достаточно простую систему параллельного исполнения.
Pascal и Delphi не упомянули...
И я так думаю что уже правильно... Время их уходит. И никакие Chrome и обещанная в этом году поддержка .NET2 в Delphi не помогут им в будущем...
).
VD>Да, уместно. Но о нем еще надо знать. А rsn81 явно не из тех кто обсуждает то, что знает.
-1
VD>Еще можно было бы упоминуть дизайн делегатов и пару других вещей.
+1
[]
VD>Языки типа Явы и C# ВООБЩЕ не рассчитаны на работу в многопоточном окружении. В них проблема гонок и неатомарности функций может возникнуть где угодно и когда угодно.
повеселил А может еще расскажешь, что такое атомарность функций?
PS: тот, кто часто использует кортежи в качестве возвращаемых значений явно что-то не то делает. Или у него слишком специфичная задача. Отсутствие кортежей — не смертельно.
А может еще расскажешь, что такое атомарность функций?