Re: офтоп
От: Кодёнок  
Дата: 27.09.05 05:33
Оценка: +1
Здравствуйте, Зверёк Харьковский, Вы писали:

Q>>...Как правильно сказал, Грехем, если ходите узнать, что будет в будущем, зайдите на факультет университета, там работают над этим будущим.


ЗХ>Был сегодня на факультете одного университета
Автор: Зверёк Харьковский
Дата: 29.03.05
, хлопотал о будущей кандидатской.

ЗХ>Зашибись* там все. Всего каких-нибудь лет 20 — и он может быть выберется из ж*пы.
ЗХ>

Смотря какой университет. Если это MIT — наверняка (именно такие универсистеты ГРехем видимо и имел ввиду). А если Уральский государственный лесотехнический УНИВЕРСИТЕТ (словосочетание-то какое

К примеру, возьмём мою кафедру. О .Net там впервые услышали в 2004 году от меня. VC6 и WinApi впервые начали преподавать где-то в 2003м. До этого Турбо Паскаль 7 и BC++ 3.1, Delphi (их и сейчас дают). Кафедра "прикладной математики и информатики", якобы использующая самые современные технологии для математического моделирования. Ага, щаз. Ну какая может быть современная мат.модель на Turbo Pascal 7 под DOS, где памяти-то ~500 Кб всего доступно? На соседних кафедрах ситуация получше, но о работе над будущим там тоже речи не идёт.

P.S. Еще российская наука явно поражена вирусом умничания. Когда я готовил магистерскую, то читал российскую и англоязычную литературу. У нас — длинные бессмысленные предложения ни о чем, вступления к статьям "с времен Адама", у них чаще сразу к делу, язык простой, даже шутки встречал пару раз в статьях.
Re[11]: Следующий язык программирования
От: Pavel Dvorkin Россия  
Дата: 27.09.05 05:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

<skipped>

PD>>Я уже не знаю, как еще объяснять. Никогда не думал, что это так сложно, хотя 20 лет преподаю. Еще раз — все я понял. Что не надо так делать — понял. Что парадигма здесь другая — понял, Что я все неправильно делаю — понял. Что я ничего не понимаю, по вашему мнению, тоже понял. Достаточно ?


AVK>Нет. Надо еще научится не делать одну и ту же ошибку в следующий раз.


Похоже, мои педагогические способности полностью исчерпались. Когда 10 раз объясняешь одно и то же, а в ответ видишь, что человек попросту не слышал твои объяснения — тяжелый случай. Не воспринимает и все!

Ладно, еще раз попробую. Постарайся просто понять, чего я хочу и не ломись в открытую дверь, доказывая мне то, что для меня совершенно очевидно. Пойми же наконец, что не об этом вообще речь идет.

Я вот недавно в очередной раз начал занятия по Win32 со студентами. Одно из первых понятий, которое там надо рассмотреть — дескрипторы. Сказал, все что на этот счет полагается, и разумеется, о том, что численное значение дескриптора для нас не важно и т.д.

А вот теперь представь себе, что приходит ко мне студент и спрашивает — а что такое дескриптор в действительности, что это число означает. (Кстати, в своем спецкурсе я этого вопроса касаюсь).

Вот мой ответ.

1. Работа с дескрипторами прозрачна для приложения, поэтому тебе это не надо знать
2. Если все же узнаешь — ты не должен это знание использовать, это некорректно.
3. То, что ты знаешь, может измениться в следующей версии Windows или даже SP, и твоя программа перестанет работать.

И т.д. Не кажется ли тебе, что эти аргументы вполне совпадают по духу с теми, которые ты пытаешься использовать ?

Только после всего этого я добавлю вот что

"Надеюсь, ты понял, что я тебе сказал и учтешь это в своей работе. А теперь я расскажу тебе, что такое дескриптор".

И дальше — недокументированная информация из Соломона-Руссиновича и Шрайбера или Фень Юаня соответственно.

Потому что бывают случаи, когда все эти 3 правила не играют никакой роли. И некорректно, и недокументировано, и непереносимо и бог знает что еще не. А жить надо, и программу сделать надо. И уж лучше ее сделать не слишком корректными способами, чем корректно ничего не сделать.

Тебе метод Руссиновича перехвата системных вызовов Win32 знаком ? (На всякий случай — это когда в ядре патчится таблица адресов системных вызовов). Метод абсолютно непереносимый, номера функций меняются от одного билда Windows к другому, приходится ссылаться на файлы символов — сам понимаешь, насколько это корректно и т.д. Но другого метода — по крайней мере я не знаю. А этот все же работает, хоть и проблем хватает. Дайте корректный способ — об этом все забудут. Так не дают...

Вот и мои вопросы вовсе не тем объясняются, что не понимаю я идеологию .Net. Прекрасно понимаю, и что то, чего я хочу, не вполне корректно — тоже понимаю. Пока меня не припрет по скорости или памяти — я и не подумаю правила нарушать. А вот если припрет — может, и придется. Потому что отказаться от C# я, вполне возможно, и не смогу, а программу делать надо.

И даже не это главное. Вопрос не столько в том, чтобы найти, где можно нарушить. Вопрос-то мой в совсем другом. Я же вижу, что попал в систему, в которой, мягко говоря, несколько иные принципы в плане эффективности исповедуются. Так вот, главное, что я понять хочу — где в ней основные неэффективнсти находятся !!! Когда я в С++ програмирую, я всегда знаю, что мне та или иная конструкция стоить будет. А здесь — пока не знаю. И вот я вижу конструкцию, которая мне подозрительной по эффективности кажется. И спрашиваю — нельзя ли здесь как-то иначе. Потому как если начну я просто писать — как бы потом не вышло, что программа будет работать с неприемлемой скоростью. Подводные камни я найти хочу и знать о них заранее...

А ты мне в ответ в 10-й раз — здесь указатели использовать нельзя и прямого доступа к памяти нет...
With best regards
Pavel Dvorkin
Re[5]: Следующий язык программирования
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.05 06:00
Оценка: 66 (5)
Здравствуйте, VladD2, Вы писали:

E>>В Ruby применяется активнейшим образом, начиная от самых базовых классов и стандартной библиотеки.


VD>Пример можно? А то ведь у миксинов много внутренних идеологических проблем.


Лучше я переведу часть главы Modules, которая касается mixin-ов, из первого издания книги Programming Ruby (поскольку она свободно доступна в Интернете). Это быстрый перевод, за особое качество не ручаюсь, так что в случае каких-то проблем прошу обращаться к первоисточнику.

Mixins

Модули имеют еще одно замечательное применение. Коротко говоря они замечательно устраняют необходимость во множественном наследовании, предоставляя возможность, называемую примесями (mixin).

В примере в предыдущем параграфе мы определили методы модуля, чьи имена имеют в качестве префикса имя модуля. Если это навело вас на мысль о статических методах класса (eao197: class method в Ruby является синонимом статического метода в C++), то вашей следующей мыслью может быть: "что же будет, если я определю не статические методы в модуле (eao197: instance method в Ruby является синонимом не статического метода в C++)?". Хороший вопрос. Не может быть экземпляров модуля, т.к. модуль не является классом. Тем не менее, вы можете включить модуль в определение класса. Когда это происходит все не статические методы модуля внезапно оказываются доступны как не статические методы класса. Они подмешаны (mixed in). Фактически, подмешанные модули становятся суперклассами.

module Debug     
  def whoAmI?     
    "#{self.type.name} (\##{self.id}): #{self.to_s}"     
  end     
end     
class Phonograph     
  include Debug     
  # ...     
end     
class EightTrack     
  include Debug     
  # ...     
end     
ph = Phonograph.new("West End Blues")     
et = EightTrack.new("Surrealistic Pillow")     
ph.whoAmI?     »    "Phonograph (#537766170): West End Blues"     
et.whoAmI?     »    "EightTrack (#537765860): Surrealistic Pillow"


Подключая модуль Debug и класс Phonograph, и класс EightTrack получают доступ к не статическому методу whoAmI?.

Несколько замечаний о предложении include перед тем как идти дальше. Во-первых, оно ничего не делает с файлами. C-программисты используют директиву препроцессора #include для включения содержимого одного файла в другой во время компиляции. В Ruby предложение include просто устанавливает ссылку на указанный модуль. Если этот модуль находится в другом файле, то вы должны сначала подключить этот файл посредством require прежде чем делать include. Во-вторых, include в Ruby не просто копирует методы модуля в описание класса. Вместо этого создается ссылка из класса на подключенный модуль. Если несколько классов подключают какой-то модуль, то все они ссылаются на одно и то же. Если вы изменяете определение метода внутри модуля, даже когда ваша программа работает, все подключившие модуль классы начнут проявлять новое поведение. [Конечно же, мы сейчас говорим только о методах. Например, атрибуты экземпляров всегда связаны со своим объектом.]

Примеси дают вам замечательный, управляемый способ добавления функциональность в класса. Но их настоящая мощь проявляется когда код в примеси начинает взаимодействовать с кодом в классе, который использует примеси. Для примера возьмем стандартную Ruby-примесь Comparable. Примесь Comparable может быть использована для добавления как операторов сравнения (<, <=, ==, >=, >), так и метода between? в класс. Для этого Comparable передполагает, что любой использующий его класс определяет оператор <=>. Поэтому, как разработчик класса вы определяете один метод <=>, делаете include Comparable и за просто так получаете шесть функций сравнения. Попробуем это с нашим классом Song сделав сравнение музыкальных композиций по времени звучания. Все, что нам нужно -- это подключить модуль Comparable и реализовать оператор сравнения <=>.

class Song
  include Comparable
  def <=>(other)
    self.duration <=> other.duration
  end
end


Мы можем проверить, что результаты получаются осмысленными с помощью нескольких тестов:

song1 = Song.new("My Way",  "Sinatra", 225)     
song2 = Song.new("Bicylops", "Fleck",  260)     
song1 <=> song2     »    -1     
song1  <  song2     »    true     
song1 ==  song1     »    true     
song1  >  song2     »    false


Наконец, на странице 43 мы показали реализацию Смоллталковской функции inject реализовав ее внутри класса Array. Мы обещали, что мы следаем ее более обобщенной. Какой же лучший путь для этого, нежели определение ее как модуля-примеси?

module Inject
  def inject(n)
     each do |value|
       n = yield(n, value)
     end
     n
  end
  def sum(initial = 0)
    inject(initial) { |n, value| n + value }
  end
  def product(initial = 1)
    inject(initial) { |n, value| n * value }
  end
end


Мы можем протестировать ее подмешав в какой-нибудь встроенный класс.

class Array     
  include Inject     
end     
[ 1, 2, 3, 4, 5 ].sum     »    15     
[ 1, 2, 3, 4, 5 ].product     »    120     

class Range     
  include Inject     
end     
(1..5).sum     »    15     
(1..5).product     »    120     
('a'..'m').sum("Letters: ")     »    "Letters: abcdefghijklm"


Для более сложного примера примеси обратитесь к документации на модуль Enumerable, которая начинается на странице 403 (eao197: on-line версия).

Instance Variables in Mixins

Люди, которые пришли в Ruby из C++, часто спрашивают нас: "Что происходит с атрибутами объектов в примесях? В C++ я могу хоть как-то управлять тем, как атрибуты разделяются в иерархиях с множественным наследованием. Как с этим справляется Ruby?".

Чтож, начинающим мы говорим, что это не очень хороший вопрос. Вспомните, как атрибуты объектов работают в Ruby: первое упоминание начинающейся с "@" переменной создает атрибут в текущем объекте self.

Для примесей это означает, что модуль, который вы вы подмешиваете в ваш клиентский класс, может создавать атрибуты в клиентском объекте и может использовать attr и подобные методы для определения setter-ов/getter-ов для этих атрибутов. Например:

module Notes
  attr  :concertA
  def tuning(amt)
    @concertA = 440.0 + amt
  end
end

class Trumpet
  include Notes
  def initialize(tune)
    tuning(tune)
    puts "Instance method returns #{concertA}"
    puts "Instance variable is #{@concertA}"
  end
end

# The piano is a little flat, so we'll match it
Trumpet.new(-5.3)


приводит к:

Instance method returns 434.7
Instance variable is 434.7


Мы не только имеем доступ к определенным в примеси методам, мы так же получаем доступ к необходимым атрибутам. Конечно же, существует риск, что разные примеси могут использовать атрибуты с одинаковыми именами, что создаст коллизию:

module MajorScales
  def majorNum
    @numNotes = 7 if @numNotes.nil?
    @numNotes # Return 7
  end
end

module PentatonicScales
  def pentaNum
    @numNotes = 5 if @numNotes.nil?
    @numNotes # Return 5?
  end
end

class ScaleDemo
  include MajorScales
  include PentatonicScales
  def initialize
    puts majorNum # Should be 7
    puts pentaNum # Should be 5
  end
end

ScaleDemo.new


результат:

7
7


Обе части подмешанного кода используют атрибу @numNotes. К сожалению, результат, вероятно, не совпадает с тем, что ожидал автор.

По большей части модули-примеси не пытаются иметь собственных атрибутов -- они использут getter-/setter-ы для получения данных из клиентских объектов. Но, если вам нужно создать примесь, которая должна иметь собственное состояние, убедитесь, что атрибут имеет уникальное имя чтобы отличать его от остальных примесей в системе (например, делая имя модуля частью имени атрибута).

Iterators and the Enumerable Module

Вероятно вы заметили, что классы коллекций в Ruby поддерживают большое число операций, которые делают с коллекциями разные вещи: перебор (traverse it), сортировка и т.д. Вы можете подумать: "Ага, я уверен, что будет классно, если мой класс так же сможет поддерживать эти замечательные возможности!" (Если вы действительно думаете так, то, возможно, пора прекращать смотреть повторы телевизионных шоу 1960-х годов).

Хорошо, ваши классы могут поддерживать все эти замечательные возможности благодоря магии примесей и модулю Enumerable. Все, что вы должны для этого сделать -- это определить называемый each итератор, который будет один за один перебирать элементы вашей коллекции. Подмещайте Enumerable и внезапно ваш класс будет поддерживать такие вещи, как map, include? и find_all?. Если объекты в вашей коллекции поддерживают осмысленное упорядочение посредством метода <=>, то вы так же получаете методы min, max и sort.

... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Следующий язык программирования
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.09.05 06:49
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Похоже, мои педагогические способности полностью исчерпались. Когда 10 раз объясняешь одно и то же, а в ответ видишь, что человек попросту не слышал твои объяснения — тяжелый случай. Не воспринимает и все!


Видишь ли, если бы трудности заключались только во мне, то можно было бы все списать на мою тупость. Но у тебя подобные же проблемы возникают со всеми собеседниками.

PD>"Надеюсь, ты понял, что я тебе сказал и учтешь это в своей работе. А теперь я расскажу тебе, что такое дескриптор".


Все это здорово и правильно. Но не стоит забывать о том, что форум это не лекция. Здесь в основном собрались практики. Отсюда и соотв. акцент. Никто и не догадывается, что ты вопрошаешь с познавательными, а не практическими целями.

PD>А ты мне в ответ в 10-й раз — здесь указатели использовать нельзя и прямого доступа к памяти нет...


Я в тех дисскусиях не участвовал
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[10]: Следующий язык программирования
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 27.09.05 07:02
Оценка:
PD>Пишу с другого компьютера, под рукой DevStudio нет. Так что по памяти...

PD>DirectoryInfo di = new DirectoryInfo("путь");

PD>FileInfo[] fi = di.GetFiles();

PD>в каталоге "путь" 100,000 файлов.


А зачем вам FileInfo на каждый файл?

Почему не ?
string[] files = Directory.GetFiles("путь");
Re[12]: Следующий язык программирования
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.09.05 07:31
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Это к тому же вопросу Вернмся к БД
Автор: Serginio1
Дата: 05.05.05

Там где нужен итератор передается массив. Но трудно себе представить каталог с 100 000 файлами, и во многих случаях массив для большинства более предпочтителен чем некий курсор (итератор). Много сделано именно для упрощения восприятия.
Плюс в новой версии файловой системы эти запросы будут выполняться намного быстрее.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Re[13]: Следующий язык программирования
От: Кодёнок  
Дата: 27.09.05 07:45
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Это к тому же вопросу Вернмся к БД
Автор: Serginio1
Дата: 05.05.05

S> Там где нужен итератор передается массив. Но трудно себе представить каталог с 100 000 файлами, и во многих случаях массив для большинства более предпочтителен чем некий курсор (итератор). Много сделано именно для упрощения восприятия.
S> Плюс в новой версии файловой системы эти запросы будут выполняться намного быстрее.

А о чем спор? массив может быть ленивым, вы работаете с ним как с массивом, но наполнение будет происходить по мере доступа путем скрытого вызова FindFirstFile/FindNextFile Любой итератор можно "обернуть" в ленивую последовательность. Будет и упрощение восприятия, и достаточная эффективность.
Re[14]: Следующий язык программирования
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.09.05 07:59
Оценка:
Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Serginio1, Вы писали:


S>> Это к тому же вопросу Вернмся к БД
Автор: Serginio1
Дата: 05.05.05

S>> Там где нужен итератор передается массив. Но трудно себе представить каталог с 100 000 файлами, и во многих случаях массив для большинства более предпочтителен чем некий курсор (итератор). Много сделано именно для упрощения восприятия.
S>> Плюс в новой версии файловой системы эти запросы будут выполняться намного быстрее.

Кё>А о чем спор? массив может быть ленивым, вы работаете с ним как с массивом, но наполнение будет происходить по мере доступа путем скрытого вызова FindFirstFile/FindNextFile Любой итератор можно "обернуть" в ленивую последовательность. Будет и упрощение восприятия, и достаточная эффективность.

Это уже будет не массив, а IList. Во многих (большинстве) случаев эффективней все же возвращать курсор (итератор), вместо массива.
В БД это нормальная практика.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Re[15]: Следующий язык программирования
От: Кодёнок  
Дата: 27.09.05 08:08
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>> Это к тому же вопросу Вернмся к БД
Автор: Serginio1
Дата: 05.05.05

S>>> Там где нужен итератор передается массив. Но трудно себе представить каталог с 100 000 файлами, и во многих случаях массив для большинства более предпочтителен чем некий курсор (итератор). Много сделано именно для упрощения восприятия.
S>>> Плюс в новой версии файловой системы эти запросы будут выполняться намного быстрее.

Кё>>А о чем спор? массив может быть ленивым, вы работаете с ним как с массивом, но наполнение будет происходить по мере доступа путем скрытого вызова FindFirstFile/FindNextFile Любой итератор можно "обернуть" в ленивую последовательность. Будет и упрощение восприятия, и достаточная эффективность.

S> Это уже будет не массив, а IList. Во многих (большинстве) случаев эффективней все же возвращать курсор (итератор), вместо массива.
S> В БД это нормальная практика.

Ну и в чём разница-то, я не пойму? Что мешает обернуть итератор в IList? А если итераторы можно еще и клонировать, то можно из них и массив со случайным доступом легко сделать (при этом итераторы без случайного доступа).
Re[6]: Следующий язык программирования
От: Зверёк Харьковский  
Дата: 27.09.05 08:30
Оценка: 3 (1) +2
Здравствуйте, VladD2, Вы писали:

ЗХ>>Ты просил — вероятность принятия индустрией нового языка, за которым не стоят монстры

ЗХ>>Я ответил

VD>Тут вот иногда народ спрашивает сколько приложений на вашем компьютере менеджед и расстраивается когда народ называет 1-3 приложения. А сколько у тебя приложений на Руби, Питоне или не дай бог на ПХП с Перлом?


VD>Боюсь столько же скольсо у меня. Максимум где-нить в каталоге скриптик заволялся.


Ну, на Python'e у меня WikidPad, в котором у меня вообще все туду-листы, быстрые заметки, фаворитсы, "на потом посмотреть" и прочая.
А на перле — несколько сотен одноразовых скриптов, написанных мной самим для повседневных нужд (типа перебрать 1000 файлов в каталоге, извлечь из них ссылки на .gif'ы, сложить в один файл).
На PHP у меня десятки мелких скриптов на imho.com.ua валяются, например rssproxy
Автор: Зверёк Харьковский
Дата: 20.08.05
.
Это не учитывая, сколько раз за день я пользуюсь приложениями на этих языках, бродя по чужим порталам.

Это так, к слову.
FAQ — це мiй ай-кью!
Re[6]: Следующий язык программирования
От: Зверёк Харьковский  
Дата: 27.09.05 08:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

ЗХ>>было X — появились Java и C# — все поняли, что Y ?

ЗХ>>(теоретически, Y == "использование байткода"?)

PD>Так-таки все приняли это ? Сомневаюсь. Кстати, идее промежуточного языка сто лет в обед — еще в ОС ИПМ для БЭСМ-6 был АЛМО. Правда, без JIT


Да, плюсы или фортран тоже не все приняли.
Да, до плюсов и фортрана тоже были ОО языки и языки высокого уровня.
Но массовый-то софт с компиляцией в байт-код начали писать именно на Java и C#.

ЗХ>>Но вопрос не в том. Вопрос в том — что должно появиться, чтобы "все поняли, что...")


PD>Хороший вопрос. Знать бы точно ответ


Вот этот вопрос я и пытался поставить в этом топике.
FAQ — це мiй ай-кью!
Re[6]: Следующий язык программирования
От: GlebZ Россия  
Дата: 27.09.05 09:04
Оценка:
Здравствуйте, eao197, Вы писали:

(eao197: class method в Ruby является синонимом статического метода в C++)....(eao197: instance method в Ruby является синонимом не статического метода в C++)?".


Терминология мне жутко понравилась. Просто и ясно, без синтетического static.

С уважением, Gleb.
Re[16]: Следующий язык программирования
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.09.05 09:08
Оценка:
Здравствуйте, Кодёнок, Вы писали:

S>> Это уже будет не массив, а IList. Во многих (большинстве) случаев эффективней все же возвращать курсор (итератор), вместо массива.

S>> В БД это нормальная практика.

Кё>Ну и в чём разница-то, я не пойму? Что мешает обернуть итератор в IList? А если итераторы можно еще и клонировать, то можно из них и массив со случайным доступом легко сделать (при этом итераторы без случайного доступа).

Например для деревьев нет понятия IList, хотя на них и можно эмулировать индексируемый доступ. Только зачем???? если курсора (итератора) для этого больше чем нужно??? В БД эта порочная практика выкорчевана. И вот она возвращается в нетовской идеологии при чем там где это противопоказано.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Re[7]: Следующий язык программирования
От: Кодёнок  
Дата: 27.09.05 09:18
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>(eao197: class method в Ruby является синонимом статического метода в C++)....(eao197: instance method в Ruby является синонимом не статического метода в C++)?".


GZ>Терминология мне жутко понравилась. Просто и ясно, без синтетического static.


В С++ дофига таких ляпов То же static в другом контексте означает изменение видимости символа для линкера.
Re[7]: Следующий язык программирования
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.09.05 09:29
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>

GZ>(eao197: class method в Ruby является синонимом статического метода в C++)....(eao197: instance method в Ruby является синонимом не статического метода в C++)?".


GZ>Терминология мне жутко понравилась. Просто и ясно, без синтетического static.




Там еще есть такие вещи как class variable (аналог статического атрибута в C++, имена class variables начинаются с "@@"), class instance variable (это атрибуты классов (в том смысле, что класс в Ruby -- это то же объект), они, имхо, доступны только в определенных контекстах) и class instance method (это метод метакласса класса).

Вообще-то отношения между классами, экземплярами классов, классов как объектов, метаклассами и пр. в Ruby не так уж и просто, я лично долго курил на эту тему. Да и сейчас детали регулярно забываются.

class instance variable и class instance method имеют непосредственное значение к метапрограммированию. Поэтому обычно с ними сталкиваться не приходится.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Следующий язык программирования
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.09.05 09:30
Оценка: 2 (2) +2
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Вот и мои вопросы вовсе не тем объясняются, что не понимаю я идеологию .Net. Прекрасно понимаю, и что то, чего я хочу, не вполне корректно — тоже понимаю. Пока меня не припрет по скорости или памяти — я и не подумаю правила нарушать. А вот если припрет — может, и придется. Потому что отказаться от C# я, вполне возможно, и не смогу, а программу делать надо.


PD>И даже не это главное. Вопрос не столько в том, чтобы найти, где можно нарушить. Вопрос-то мой в совсем другом. Я же вижу, что попал в систему, в которой, мягко говоря, несколько иные принципы в плане эффективности исповедуются. Так вот, главное, что я понять хочу — где в ней основные неэффективнсти находятся !!!

Ты пытаешься сделать это очень странным методом. Ни по одному из вопросов, которые ты задаешь, не видно, что ты исследуешь эффективность дотнета.
Ну какое отношение к эффективности имеет возможность декларировать вложенные структуры в методах?
PD>Когда я в С++ програмирую, я всегда знаю, что мне та или иная конструкция стоить будет. А здесь — пока не знаю. И вот я вижу конструкцию, которая мне подозрительной по эффективности кажется. И спрашиваю — нельзя ли здесь как-то иначе. Потому как если начну я просто писать — как бы потом не вышло, что программа будет работать с неприемлемой скоростью. Подводные камни я найти хочу и знать о них заранее...
Угу. При этом ты почему-то вместо прямого вопроса типа "насколько дорого стоит A a = new A() для value-типов" начинаешь задавать совершенно другие вопросы, типа "как занулить все поля структуры, но по-другому, чем мне советуют".

Ты подходишь к дотнету с плохо скрытым внутренним вопросом типа "не правда ли, это тормозной и прожорливый отстой?" Это неправильный вопрос. Пока ты будешь им задаваться, никакого успеха ты не достигнешь. Надо ставить вопрос так: "Как писать эффективные приложения на дотнет?" Как ни странно, это возможно.
PD>А ты мне в ответ в 10-й раз — здесь указатели использовать нельзя и прямого доступа к памяти нет...
Верно. В общем, основная неэффективность в дотнете — это неэффективность слепого переноса привычных паттернов из других языков.


В общем и целом, этот вопрос уже поднимался не один раз. И в том числе на RSDN.
Для того, чтобы пользоваться дотнетом, надо научиться ровно одному — доверять рантайму. Ты уже доверяешь компилятору плюсов и тебе это кажется очевидным. (Хотя я вот лично знаю людей, которые до сих пор с подозрением относятся к плюсам и искренне полагают, что могут порвать любой компилер своими ассемблерными вставками. Увы, я пока ни разу не видел реального примера, где бы рвался хотя бы VC7.1 в релизе, не говоря уже про Intel)

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

И это все еще про джаву! А дотнет предоставляет еще больше средств повышения производительности. Как минимум, это value-типы, которых в джаве нет (тем не менее, веб приложения на джаве крайне трудно порвать хардкорным cgi на плюсах).
Кроме того, если тебе захочется написать в форум что-то типа "вот на плюсах я банально вызывал вот такую функцию из kernel32 и был щаслив", то не пиши это в форум. Банально вызови вот такую функцию из kernel32 через PInvoke и будь щаслив. В плюсах ты получаешь некоторую экномию времени только благодаря тому, что для тебя уже написаны тонны хидеров, корректно импортирующих все что надо. Для С# аналогом является http://pinvoke.net/. Все, что ты захочешь запэинвокать в ближайший год, там уже декларировано.

Удачи!
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Следующий язык программирования
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 27.09.05 09:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


A>>Прошу прощения, а разве "развился" не понимает по собой хоть какой-то обратной совместимости?

A>>Что общего у VB6 и VB.NET? Синтаксис?

VD>99%. А что?


Ничего
С тем, что сохранился синтаксис, я как раз не спорю.

VD>Другое дело, что изменилась компонентная модель. А это действительно привело к тому, что реальные приложения переносить трудно.


Именно. Что и означает потерю обратной совместимости.

Короче, в твоем утверждении нет тезисов, с которыми бы я спорил.
Re[13]: Следующий язык программирования
От: Pavel Dvorkin Россия  
Дата: 27.09.05 10:03
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Pavel Dvorkin, Вы писали:


AVK>Все это здорово и правильно. Но не стоит забывать о том, что форум это не лекция. Здесь в основном собрались практики. Отсюда и соотв. акцент. Никто и не догадывается, что ты вопрошаешь с познавательными, а не практическими целями.


Вот это слегка настораживает. В моем любимом форуме по Win32 тоже не теоретики собрались. Теоретики — это в С++, там любителей о шаблонах , паттернах и т.д. поговорить сколько угодно. Но если в Win32 зададут вопрос типа "как перехватить...", то не будут ему объяснять битый час, что некорректно это перехватывать, а ответят по существу, если возможно.

А из общения в форуме .Net у меня какое-то впечатление сложилось, будто я с людьми разговариваю, для которых все правило даны свыше, и даже малейшая попытка их не то чтобы под сомнение поставить, а просто спросить, можно ли иначе, сразу к анафеме ведет. Ну ладно, готов я (допустим) в Иисуса Христа поверить, но вот в то, что он ходил по воде аки по суху — не могу . Или хоть объясните, как это хождение с физикой согласуется. Нет, отвечают мне, за такие вопросы ждут тебя ад и черти со сковородками.

PD>>А ты мне в ответ в 10-й раз — здесь указатели использовать нельзя и прямого доступа к памяти нет...


AVK>Я в тех дисскусиях не участвовал


Сорри. Я тут подискутировал в .Net и решил просто заглянуть в Философию. Тут попалось мне письмо Зверька, ну я и ответил, что в тот момент в голову пришло. А тут ты со своим очередным объснением, что я не понимаю, что 2*2=4. Ну под горячую руку
With best regards
Pavel Dvorkin
Re[14]: Следующий язык программирования
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.09.05 10:10
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Иисуса Христа поверить, но вот в то, что он ходил по воде аки по суху — не могу . Или хоть объясните, как это хождение с физикой согласуется. Нет, отвечают мне, за такие вопросы ждут тебя ад и черти со сковородками.
За счет внутреннй энергии.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Re[13]: Следующий язык программирования
От: Pavel Dvorkin Россия  
Дата: 27.09.05 10:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

Рад видеть тебя и здесь .

S>Ты пытаешься сделать это очень странным методом. Ни по одному из вопросов, которые ты задаешь, не видно, что ты исследуешь эффективность дотнета.


А за каким богом мне тогда вопрос о memset задавать было ?

S>Ну какое отношение к эффективности имеет возможность декларировать вложенные структуры в методах?


Это — не имеет. Это просто был вопрос о том, можно или нет. Чтобы знать на случай портирования. Потому как написал я это по привычке, а компилятор ругается. И ответили мне сразу, и закрыть вопрос можно было, хоть и высказал я некоторое недовольство. А тут началась вселенская дискуссия

S>Угу. При этом ты почему-то вместо прямого вопроса типа "насколько дорого стоит A a = new A() для value-типов" начинаешь задавать совершенно другие вопросы, типа "как занулить все поля структуры, но по-другому, чем мне советуют".


Именно. Потому что (еще раз объясняю) я не знаю, где тут возможные проблемы имеются. И когда вижу нечто, мне подозрительное, спрашиваю. нельзя ли это сделать способом, который мне хорошо знаком и никаких сомнений не вызывает. А начни я спрашивать про все конструкции — тогда для меня отдельный форум придется создать

S>Ты подходишь к дотнету с плохо скрытым внутренним вопросом типа "не правда ли, это тормозной и прожорливый отстой?"


Можешь думать, что тебе хочется, но в данном случае ты не прав. Я подхожу к нему совершенно нейтрально. Я подхожу с вопросом вот каким. Мне предлагается новый для меня инстумент. Кто его хвалит, кто нет — я это принимать во внимание сейчас не буду. Я одно хочу знать — смогу ли я на нем делать с той же эффективностью то, что я умею делать.

Если бы (допустим) я С++ не знал, а переходил на него с Паскаля (кстати, и не допустим — было такое в моей жизни), то я бы не сомневался в том, что смогу. Надо только конструкции новые понять, ругнуться несколько раз по поводу кошмарного синтаксиса (по сравнению с Паскалем , а вообще-то это средства примерно равномощные (не придирайся только к этим словам) и эффективность будет та же. И то подводные камни в этом плане есть, и не мешало бы их знать, прежде чем что-то серьезное делать. А тут мне предлагается инструмент, в котором эффективнсть бог знает какая, то ли компилятор, то ли интерпретатор, механизмы для меня непривычные, чему можно верить — не знаю, пробую элементарное (DirectoryInfo) — получаю кошмар. Где еще проблемы ТАКОГО рода скрыты? Не знаю. Подозреваю все. И new для value тоже.

>Это неправильный вопрос. Пока ты будешь им задаваться, никакого успеха ты не достигнешь. Надо ставить вопрос так: "Как писать эффективные приложения на дотнет?" Как ни странно, это возможно.


Вот это уже лучше. Я и хочу это понять, Я и недоволен тем, что то, что должно быть эффективным (потому что я очень даже хорошо знаю, что здесь делается хоть на уровне kernel32, хоть ntdll.dll, хоть даже ntoskrnl, вдруг 57 Мбайт требует. И что еще меня подобное здесь ждет ?



S>В общем и целом, этот вопрос уже поднимался не один раз. И в том числе на RSDN.

S>Для того, чтобы пользоваться дотнетом, надо научиться ровно одному — доверять рантайму. Ты уже доверяешь компилятору плюсов и тебе это кажется очевидным.

Черта с два. Я просто знаю, на что он это компилирует. А если малейшие сомнения появятся, посмотрю дизассембленрный код. Но, конечно, я реально знаю, что и как можно делать.


(Хотя я вот лично знаю людей, которые до сих пор с подозрением относятся к плюсам и искренне полагают, что могут порвать любой компилер своими ассемблерными вставками. Увы, я пока ни разу не видел реального примера, где бы рвался хотя бы VC7.1 в релизе, не говоря уже про Intel)

Ну это особая тема. Если хочешь, можно подискутировать как-нибудь.

S>Ты не один такой. Для подавляющего большинства разработчиков на плюсах переход на управляемую среду связан с преодолением внутреннего барьера. Я в свое время сломал этот барьер после того, как увидел своими глазами мейл-релей на чистой джаве, который рвал своего нативного аналога примерно в пять раз по производительности.

S>После этого я начал понимать, что в очень широком классе приложений затраты на "управляемость" пренебрежимо малы по сравнению с простоями, вызванными неэффективными алгоритмами. А алгоритмические оптимизации более чем доступны и в дотнет.

Дело в том, что есть задачи разных классов. И трудно сказать, где и что может всплыть. Я же не спорю, что Java для апплетов хорошо подходит. Но да помилуй бог того, кто вздумает PhotoShop на Java написать.

S>Кроме того, если тебе захочется написать в форум что-то типа "вот на плюсах я банально вызывал вот такую функцию из kernel32 и был щаслив", то не пиши это в форум. Банально вызови вот такую функцию из kernel32 через PInvoke и будь щаслив. В плюсах ты получаешь некоторую экномию времени только благодаря тому, что для тебя уже написаны тонны хидеров, корректно импортирующих все что надо. Для С# аналогом является http://pinvoke.net/. Все, что ты захочешь запэинвокать в ближайший год, там уже декларировано.


Был там. Естественно, это хорошо, но проблему не решает. Я там могу Win32 функции вызывать, ну а свои собственные ? К примеру (банальный) решиться мне, скажем, на C# матричные операции производить или же С++ DLL для этого написать, а в Шарпе только вызывать ее. Только не подумай, что я тебе этот вопрос задаю. Их много, таких вопросов...

S>Удачи!


Спасибо!
With best regards
Pavel Dvorkin
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.