Здравствуйте, Lloyd, Вы писали:
G>>>Ускоряет численные рассчеты раз в 25.
VD>>Ага, а нада на порядок.
L>На порядок == в 10 раз быстрее. Ты считаешь, что Psyco не следовало делать таким быстрым?
Сри, неврено прочел. 25 — это просто нереальная цифра. Хороший интерпретатор приблизительно в 10-15 раз медленее компилятора. Получается, что Пико делает код в 2-2.5 раза быстрее чем оптимальный ассемблерынй код.
Думаю, реальная цифра бдет 2-10 раз.
Рельные же (не подтасованные) эксперементы показывают, что Пико до типизированных джитов как до луны.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
VD>Я же говорю о языках которые проектировались как "тайплес". Несомненно для разных Руби, Питовно, Смолтоков и Лиспом можно и ружно делать джиты и т.п. Но сам дизайн языков припятствует полному устранению интерпретируемости.
Не знаю на счет Python, Smalltalk и Lisp, но, имхо, некоторые сильные стороны Ruby как раз и обеспечиваются тем, что Ruby является интерпретируемым языком. Отними эту интерпретируемость и достоинства Ruby просто-напросто испарятся.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Сколько на скриптах кода написано... некоторым "высокоуровневым языкам" и не снилось. CS>>Взять тот же PHP.... CS>>Вот кстати феномен тоже. Язык рождался на ходу, соответсвенно всякие несуразицы в синтаксисие. CS>>Но ежики плачут но лезут на кактус... И нафиг никому по большому счету не упали ни классы ни наследование ни JIT. CS>>Язык для народа. И народ на нем пишет. И красиво кстати пишет...
VD>Думаю, что популярность ПХП определяется не его качествами как языка, а тем что он входит в набор доступных средств на супер дешевых хостингах (а то и халавнях) где хостится этот самый народ (а точнее низкоквалифицированные орлы у которых нет денег на серьезный хостинг). Ну, а то что некоторые более менее серьезные сайты подсели на ХПХ объясняется тем, что ПХП-массы обеспечивают массу дешевейших рабочих рук которые естественно выбирают то что знают.
"хостится этот самый народ" ... я тоже
Не знаю как по поводу тових причин...
Я например выбрал именно PHP (не зная его совершенно) потому как
a) легко понимаю нотацию, b) хорошо понимаю вычислительную модель
с) добра на нем написано....
стили, раскладку и подгон под то чтобы можно было
писать статьи в BlockNote.
Forum на terrainformatica.com — с нуля — два дня.
Весь сайт — еще четыре.
VD>Лично я скорее выучу Лисп и начну писать не нем, чем прибегну к ПХП. Так что ПХП — это как и ЯваСкрипт... просто так легла карта. Но в отличии от ЯваСкрипт вместо ПХП можно легко проименять полноценные языки, так как клиент видит только результат в виде ХТМЛ. А вот ЯваСкрипт засел в браузерах надолго... стандарт однако.
Полноценность...
Берусь утверждать что для задач решаемых PHP (website generation ) полноценен на 99%
Re[11]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, c-smile, Вы писали:
CS>Не знаю как по поводу тових причин... CS>Я например выбрал именно PHP (не зная его совершенно) потому как CS>a) легко понимаю нотацию, b) хорошо понимаю вычислительную модель CS>с) добра на нем написано....
Так же ты нашел бы тоже самое и на C# с Явой.
CS>Forum на terrainformatica.com — с нуля — два дня. CS>Весь сайт — еще четыре.
Посмотрите на этот мир и посмотрите на эти шатны (с) анекдот.
CS>Берусь утверждать что для задач решаемых PHP (website generation ) полноценен на 99%
А я бурусь утверждат, что если задача сложнее гостевухи на личной страничке, то Ява и Шарп с их фреймворками куда более удобне и полноеценное решение. Ну, а лабать сайты можно и на VBScript. Тоже себе полноценное решение.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, eao197, Вы писали:
E>Не знаю на счет Python, Smalltalk и Lisp, но, имхо, некоторые сильные стороны Ruby как раз и обеспечиваются тем, что Ruby является интерпретируемым языком. Отними эту интерпретируемость и достоинства Ruby просто-напросто испарятся.
Согласен и даже скажу больше. Многие сильные стороны других перечисленных языков тоже заточены на интерпретируемость и безтиповость. Однако это всего лишь упрощает задачу. Но все тоже самое можно реализовать и в компилируемых, строготипизированных средах. Просто тут нужны уже более мощьные которы и технологии.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Не знаю как по поводу тових причин... CS>>Я например выбрал именно PHP (не зная его совершенно) потому как CS>>a) легко понимаю нотацию, b) хорошо понимаю вычислительную модель CS>>с) добра на нем написано....
VD>Ты не понимашь нотации C# или Явы? VD>На этих языках написано мало добра?
Много. Но что-то мне кажется что на PHP больше всякого под inet сделано.
Во всяком случае у PHP своя ниша и большая — малогабаритные системы.
Те же Wiki, Blog'и и прочие PHPBB. Все вместе взятое по количесву инсталляций с C# и не подходи.
Рискну заметить что если Апач то это PHP в 90% случаев.
1) Ты знаешь — не нашел. Если покажешь пальцем буду признателен.
2) Зачем мне на мой Апач JSP ставить? А тем более C# (ASP.NET)?
CS>>Forum на terrainformatica.com — с нуля — два дня. CS>>Весь сайт — еще четыре.
VD>Посмотрите на этот мир и посмотрите на эти шатны (с) анекдот.
Угу. "Дешево и сердито"
CS>>Берусь утверждать что для задач решаемых PHP (website generation ) полноценен на 99%
VD>А я бурусь утверждат, что если задача сложнее гостевухи на личной страничке, то Ява и Шарп с их фреймворками куда более удобне и полноеценное решение. Ну, а лабать сайты можно и на VBScript. Тоже себе полноценное решение.
На VBScript? Говорят можно, но не видел вживую изнутри чего-то настоящего..
Если мы говорим про web services или web applications то там да, имеет место и смысл быть Яве или Шарпу.
Но сайты для народа — с выше перечисленными компонентами — этим стрелять по воробьям не надо.
Re[9]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
E>>Не знаю на счет Python, Smalltalk и Lisp, но, имхо, некоторые сильные стороны Ruby как раз и обеспечиваются тем, что Ruby является интерпретируемым языком. Отними эту интерпретируемость и достоинства Ruby просто-напросто испарятся.
VD>Согласен и даже скажу больше. Многие сильные стороны других перечисленных языков тоже заточены на интерпретируемость и безтиповость. Однако это всего лишь упрощает задачу. Но все тоже самое можно реализовать и в компилируемых, строготипизированных средах. Просто тут нужны уже более мощьные которы и технологии.
Вот по поводу выделенного у меня есть определенные сомнения. В Ruby существует специальный термин "Duck Typing":
In Ruby, the class is never (OK, almost never) the type. Instead, the type of an object is
defined more by what that object can do. In Ruby, we call this duck typing. If an object
walks like a duck and talks like a duck, then the interpreter is happy to treat it as if it
were a duck.
(Programming Ruby, 2nd edition).
Этот термин определяет одну из важнейших концепций Ruby (возможно в Python и Smalltalk тоже самое): для того, чтобы объект мог принимать участие в какой-то операции всего лишь требуется, чтобы объект предоставлял методы, используемые в данной операции (похоже на шаблоны в C++). Приведу несколько примеров для иллюстрации (из той же книги Programming Ruby).
Предположим, что нам нужно иметь структуру, которая хранит информацию о клиенте и позволяет записывать эту информацию в указанный файл:
class Customer
def initialize(first_name, last_name)
@first_name = first_name
@last_name = last_name
end
def append_name_to_file(file)
file << @first_name << " " << @last_name
end
end
Для проверки работоспособности класса Customer создаем Unit-тест:
require 'test/unit'
require 'addcust'
class TestAddCustomer < Test::Unit::TestCase
def test_add
c = Customer.new("Ima", "Customer")
f = File.open("tmpfile", "w") do |f|
c.append_name_to_file(f)
end
f = File.open("tmpfile") do |f|
assert_equal("Ima Customer", f.gets)
end
ensure
File.delete("tmpfile") if File.exist?("tmpfile")
end
end
Test-case с именем test_add создает объект типа Customer и записывает его в файл tmpfile. Затем открывает этот же файл для чтения и проверяет, что информация была правильно в него записана. И на последок, чтобы не оставлять после себя мусора, tmpfile удаляется.
Благодоря duck typing этот test-case можно упростить, поскольку для Customer#append_name_to_file нужен объект, который поддерживает оператор <<. В Ruby это не только файл, но и String:
require 'test/unit'
require 'addcust'
class TestAddCustomer < Test::Unit::TestCase
def test_add
c = Customer.new("Ima", "Customer")
f = ""
c.append_name_to_file(f)
assert_equal("Ima Customer", f)
end
end
А так же и Array:
require 'test/unit'
require 'addcust'
class TestAddCustomer < Test::Unit::TestCase
def test_add
c = Customer.new("Ima", "Customer")
f = []
c.append_name_to_file(f)
assert_equal(["Ima", " ", "Customer"], f)
end
end
Т.е. благодоря duck typing объект Customer может работать с гораздо большим количеством классов, чем это предполагалось ранее. Что, вообще-то говоря, дает большую гибкость использования объектов Customer. В статически типизируемых языках метод append_name_to_file должен был бы получать в качестве пераметра какой-то интерфейс. Скажем std::ostream в C++. Но в том же C++ ни std::string, ни std::vector (list, deque) не являются наследниками std::ostream. Подозреваю, что в C# и Java с потоками ввода-вывода и классами String, ArrayList и пр. такая же ситуация. И чтобы достичь в статически типизированном языке такого же эффекта, нужно будет для String/Vector писать какую-то обертку, реализующую нужный интерфейс. В С++ это можно было бы сделать на шаблонах:
class Customer
{
std::string first_name_;
std::string last_name_;
public :
...
template< class Receiver >
void append_name_to_file( Receiver & f )
{
f << first_name_ << " " << last_name_;
}
};
// Обертка для предоставления возможности сохранения содержимого Customer в строку.class String_As_Receiver
{
std::string & receiver_;
public :
String_As_Receiver( std::string & receiver ) : receiver_( receiver ) {}
String_As_Receiver &
operator<<( const std::string & what )
{
receiver_.append( what );
return *this;
}
};
// Обертка для предоставления возможности сохранения содержимого Customer в вектор (список, дек).template< class Container >
class Container_As_Receiver
{
Container & receiver_;
public :
Container_As_Receiver( Container & receiver ) : receiver_( receiver ) {}
Container_As_Receiver &
operator<<( const std::string & what )
{
receiver_.push_back( what );
return *this;
}
};
// А теперь использование всего этого безобразия.
Customer c( "Ima", "Customer" );
{
std::ofstream f( "tmpfile" );
c.append_name_to_file( f );
}
{
std::string s;
String_As_Receiver r( s );
c.append_name_to_file( r );
}
{
std::vector v;
Container_As_Receiver r( v );
c.append_name_to_file( r );
}
Т.е. получаем практически такой же эффект, но гораздо большими усилиями.
Конечно, кто-то задастся вопросом, а зачем вообще такая гибкость нужна? Лично мне кажется, что эта гибкость необходима для сопровождения кода, когда для внесения значительных изменений потребуется сделать всего несколько модификаций. И, что интересно, в Programming Ruby приводится похожий пример из реального Web-приложения. В этом приложении была возможность даунлоада содержимого некоторой базы в CSV формате. И при нагрузочном тестировании буквально перед запуском оказалось, что операция CSV выполняется недопустимо долго. Оказалось, что проблема была в коде:
def csv_from_row(op, row)
res = ""
until row.empty?
entry = row.shift.to_s
if /[,"]/ =~ entry
entry = entry.gsub(/"/, '""')
res << '"' << entry << '"'
else
res << entry
end
res << "," unless row.empty?
end
op << res << CRLF
end
result = ""
query.each_row {|row| csv_from_row(result, row)}
http.write result
На больших объемах входных данных этот код сильно тормозил. Оказалось, что дело в garbage collector-е. По мере роста результирующей строки result переодически запускался GC который прибивал множество небольших временных строк res, которые образовывались на каждой итерации цикла.
Для того, чтобы преодолеть эту проблему был просто заменен тип переменной result -- вместо String, который сохранял свое значение в непрерывном блоке памяти, применили Array, который хранил свое содержимое как множество мелких объектов:
def csv_from_row(op, row)
# Код не изменился.
end
result = []
query.each_row {|row| csv_from_row(result, row)}
http.write result.join
Конечно же, можно говорить, что у разработчиков и руки кривые, и что они сразу не увидели, что здесь может быть замедление работы, и еще что-нибудь Только, имхо, здесь был полностью задействован принцип о преждевременной оптимизации. Сначала получили работающий корректный код. А потом, изменив всего две строки, сделали его быстрым.
Вот такая вот у duck typing гибкость. Правда расплачиваться за нее приходится скоростью исполнения (и большим количеством unit-test-ов, что вряд ли плохо). Но я сомневаюсь, что в статически-типизированных языках можно достичь чего-нибудь подобного. Да и если можно, то на это время потребуется. А в Ruby (вероятно и в Python, Smalltalk, etc) это есть уже сейчас.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Задумчиво так...: нужен ли народу scripting?
Имхо, duck typing от Unintrusive Retroactive Polymorphism все же отличается. Как я понял, если какой-то класс пытаются выдать за интерфейс, то в этом классе должны быть реализованы все методы интерфейса. Т.е., если бы в приведенном по ссылке примере:
types {
class Dog {
MakeSound() : String {
return "woof";
}
GetNumLegs() : Int {
return 4;
}
GoFetch() {
// ...
}
}
class Duck {
GetNumLegs() : Int {
return 2;
}
MakeSound() : String {
return "quack";
}
FlySouth() {
// ...
}
}
interface IAnimal {
MakeSound() : String;
GetNumOfLegs() : Int;
// Был бы еще вот такой метод.GoAway();
}
}
То следующий код, как я понимаю, не скомпилировался бы:
functions {
_main() {
IAnimal& animal;
Dog dog;
Duck duck;
// Здесь следовало бы ожидать ошибку, т.к. у Dog нет метода GoAway.
animal = @dog;
P(animal.MakeSound()); // outputs woof
// И здесь так же.
animal = @duck;
P(animal.MakeSound()); // outputs quack
}
}
Или я ошибаюсь?
А вот в duck typing все же не требуется от объекта иметь все методы, которые у него могут потребоваться. Например:
class Dog
def make_sound; "woof" end
def get_num_legs; 4 end
def go_fetch; end
end
class Duck
def make_sound; "quack" end
def get_num_legs; 2 end
def fly_south; end
end
class Cat
def make_sound; "miau" end
def get_num_legs; 4 end
def go_away!; puts "Frrrrr!" end
end
def play_with_animal( animal )
sound = animal.make_sound
if "woof" != sound && "quack" != sound
animal.go_away!
else
puts "I like animal with sound '#{sound}'"
end
end
play_with_animal Dog.new
play_with_animal Duck.new
play_with_animal Cat.new
в результате выполнения получаем:
I like animal with sound 'woof'
I like animal with sound 'quack'
Frrrrr!
и никаких ошибок. Аналогичные штуки с C++ шаблонами можно делать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
VD>Так что ПХП — это как и ЯваСкрипт... просто так легла карта. Но в отличии от ЯваСкрипт вместо ПХП можно легко проименять полноценные языки, так как клиент видит только результат в виде ХТМЛ. А вот ЯваСкрипт засел в браузерах надолго... стандарт однако.
А яваскрипт-то в качестве скрипта чем плох?
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[13]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, c-smile, Вы писали:
CS>Много. Но что-то мне кажется что на PHP больше всякого под inet сделано.
Не думаю.
CS>Во всяком случае у PHP своя ниша и большая — малогабаритные системы. CS>Те же Wiki, Blog'и и прочие PHPBB. Все вместе взятое по количесву инсталляций с C# и не подходи.
По количеству несомненно. Но по деньгам уже ПХП рядом не валялся.
CS>Рискну заметить что если Апач то это PHP в 90% случаев.
Этому ресурсу я неверю уже давно. Он явно предвзят.
VD>>Так же ты нашел бы тоже самое и на C# с Явой.
CS>1) Ты знаешь — не нашел.
Плохо искал. У нас мужики быстро нашли.
CS>Если покажешь пальцем буду признателен.
Спроси что взяли на GDN для блогов.
CS>2) Зачем мне на мой Апач JSP ставить? А тем более C# (ASP.NET)?
Чтобы не возиться с куцым и убогим ПХП. Ну, и плюс... вдруг у тебя нагрузки большие. Тогда компилируемый и типизированный язык точно даст приемущество.
CS>На VBScript? Говорят можно, но не видел вживую изнутри чего-то настоящего..
90% ASP сайтов.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
E>>Вот такая вот у duck typing гибкость.
VD>Это гибгатьс на грани фола. А скорее за гранью. Нет проблем выражать полиморфизм явно. Делегаты и интерфейсы еще никто не отменял.
Вот что интересно: год назад я бы еще более грубо по этому поводу высказался бы. А сейчас уже привык, почти. Удобно, однако. Сам не ожидал.
19. A language that doesn't affect the way you think about programming, is not worth knowing.
Здравствуйте, eao197, Вы писали:
E>Простота Ruby мне кажется весьма обманчивой. Чем больше я его изучаю, тем больше думаю, что он не намного проще C++. А может быть и вовсе не проще.
Это терминалогический спор. Я говорю о простоте использования.
... << RSDN@Home 1.2.0 alpha rev. 611>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Задумчиво так...: нужен ли народу scripting?
Здравствуйте, VladD2, Вы писали:
E>>Простота Ruby мне кажется весьма обманчивой. Чем больше я его изучаю, тем больше думаю, что он не намного проще C++. А может быть и вовсе не проще.
VD>Это терминалогический спор. Я говорю о простоте использования.
