delphi = pascal = языки для начинающих

← →
Плохиш © (2007-11-14 00:18) [40]

> Юрий Зотов © (13.11.07 23:30) [37]
> > Kostafey © (13.11.07 23:24) [35]
>
> А я на них практически не бываю. Оригинальная документация
> от Sun, IBM и производителей библиотек - этого, как правило,
> достаточно. А когда недостаточно

Мне в этом случае знания делфи и справка по делфи 7 очень помогала :-)
Искал с полтора года назад причину неадекватности обработки нажатий кнопок в java-проги, написаной java-программистом, так там вместо того, чтобы сказать, что обрабатывать нажатие кнопки дальше не надо, установкой key в 0, такое наварочено было 8-O

← →
Германн © (2007-11-14 01:43) [41]

> Юрий Зотов © (13.11.07 23:19) [33]
>
> > Kostafey © (13.11.07 23:09) [30]
>
> Вот уже года полтора пишу на джаве. Ощущение такое, что
> после гоночного велосипеда сел на трехколесный. Вроде бы,
> тоже едет, но как-то не очень...
> :о)
>

Ну у тебя хватило ума чтобы использовать детский трёхколёсный как самокат, потому он всё-таки едет. А некоторые и с этим не справляются, поскольку пытаются ехать сидя на сиденьи(седле) и крутя педали.
:-)

← →
Marser © (2007-11-14 01:55) [42]

> Delphi - это среда.

А я думаю, что Delphi это тяпница! Ибо также приятна! :-))

← →
Германн © (2007-11-14 02:02) [43]

> Marser © (14.11.07 01:55) [42]
>
>
> > Delphi - это среда.
>
> А я думаю, что Delphi это тяпница! Ибо также приятна! :-
> ))
>

Т.е. приятна, когда её выключаешь? :-)

← →
Marser © (2007-11-14 02:07) [44]

А если честно, то меня в Яве всё-таки больше всего завораживает кросс-платформенность. А недостатки, описанные ЮЗ - так а разве в С# не та же история? Се путь интерпритируемых языков, использующих виртуальную машину.

Помнится, то ли в конце 2004, то ли в начале 2005 сидели мы в Киеве с Deep"ом, Пашей и Andrey"ем (его здесь только старожилы могут помнить, это "дремучая " тусовка) и Витя мне говорил о .NET и о том, что всё идёт к тому, чтобы шаловливые ручки программиста ограничивать от засовывания куда не следует, что оттуда и .NET и Java, и очень мне запомнилось, что я тогда ещё агрессивно плевался и грозился, что свалю в embedded.
Прошло почти три года. Всё это время я работал, сперва студентом, а сейчас уже и полноценно. Не под руководством опытного наставника, а, как правило, впереди паровоза, там, где окружающие мало чем могли помочь.
И вот что совсем уж странно, теперь я бы так громко не плевался. Романтический подход умер, что ли...

← →
Marser © (2007-11-14 02:08) [45]

> Германн © (14.11.07 02:02) [43]
>
>
> > Marser © (14.11.07 01:55) [42]
> >
> >
> > > Delphi - это среда.
> >
> > А я думаю, что Delphi это тяпница! Ибо также приятна!
> :-
> > ))
> >
>
> Т.е. приятна, когда её выключаешь? :-)

Да нет... Приятно работать :-)
Конечно, в D2006 уже не совсем то, что в D6-7, но всё-таки :-)

← →
Piter © (2007-11-14 02:09) [46]

Юрий Зотов © (13.11.07 23:02) [29]
Вдобавок: отсутствие указателей и средств прямого управления памятью, автоматический подсчет ссылок и сборка мусора - все это, конечно, позволяет програмисту уделить большее внимание решению прикладной задачи и подстраховывает его от ошибок. Но, с другой стороны, лишает его мощных возможностей, предоставляемых хоть теми же указателями.

Для программиста начинающего важнее первое (все равно пользоваться указателями он, как правило, толком не умеет). Для программиста опытного важнее второе (а ошибок управления памятью он уж как-нибудь и сам не допустит). Почему я и говорю - язык хорош для детского сада, но плох для профи

именно поэтому наверное в той же гребанной америке это язык по популярности номер 1, да?

Юрий Зотов © (13.11.07 23:02) [29]
а ошибок управления памятью он уж как-нибудь и сам не допустит

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

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

← →
Германн © (2007-11-14 02:16) [47]

> Marser © (14.11.07 02:08) [45]

> Конечно, в D2006 уже не совсем то, что в D6-7, но всё-таки
> :-)

Лично для меня, BDS2006 - это "вообще не то". Наверно в душе я - консерватор. :-)
Или "суперстар" :-)

← →
Marser © (2007-11-14 02:20) [48]

> Piter © (14.11.07 02:09) [46]

IMHO, ЮЗ это всё понимает не хуже твоего. Правого в этом споре нет, а занятые стороны - условности, ну, может возрастное, у обоих, причём :-))
Всё же "величие истинного пути" не в выборе среды и болтологии по поводу её преимуществ, а в наилучшей реализации поставленной задачи в имеющихся условиях (во задвинул, по-военному :-)) )

> Германн © (14.11.07 02:16) [47]

Тёзка, верите, нет? Сам бы ни за какие коврижки не перешёл! :-)

← →
Германн © (2007-11-14 02:39) [49]

> > Германн © (14.11.07 02:16) [47]
>
> Тёзка, верите, нет? Сам бы ни за какие коврижки не перешёл!
> :-)
>

Дык а какие у меня основания не верить? Верю конечно (Давно здесь сидим:). "Заставили гады перейти".
А я и не переходил и не собираюсь. Мои проекты как были в Д4 и Д6, так там и остались.
Наверно те коврижки продаются мне и тебе по разной цене. :-)

← →
Черный Шаман (2007-11-14 05:35) [50]

> Юрий Зотов © (13.11.07 23:02) [29]
>
> > Kostafey © (13.11.07 22:36) [27]
>
>
> Для программиста начинающего важнее первое (все равно пользоваться
> указателями он, как правило, толком не умеет). Для программиста
> опытного важнее второе (а ошибок управления памятью он уж
> как-нибудь и сам не допустит). Почему я и говорю - язык
> хорош для детского сада, но плох для профи.

Для индусов еще очень хорош. С Java термин "стадо программистов" приобретает довольно практичный смысл.

← →
@!!ex © (2007-11-14 07:42) [51]

> [47] Германн © (14.11.07 02:16)

Я думал я один такой... :)
У меня до сих пор Д7.
ХОтя на работе и приходится под БДС компилировать.

← →
Gydvin © (2007-11-14 07:53) [52]

Д7 - Д6 вообще класика )
И помоему самая удачная реализация среды.

а на БСД 2006 (у меня турбо эксплорер) чета вообще нет никого желания переходить

← →
Eraser © (2007-11-14 11:05) [53]

> Gydvin © (14.11.07 07:53) [52]

и не надо. нужно переходить на delphi 2007.
приемуществ, по сравнению с D7, множество. Как в редакторе кода, так и в батонокидательстве.

← →
boa_kaa © (2007-11-14 11:56) [54]

> Marser © (14.11.07 02:07) [44]
> А недостатки, описанные ЮЗ - так
> а разве в С# не та же история?

Не та же. Причем совершенно не та же.

← →
Kolan © (2007-11-14 11:59) [55]

> delphi = pascal = языки для начинающих

Начать надо с того, что delphi <> pascal

← →
Rouse_ © (2007-11-14 12:01) [56]

> именно поэтому наверное в той же гребанной америке это язык
> по популярности номер 1, да?

В штатах обьем кода мал - там народ давно на индусов переключился :)

← →
Игорь Шевченко © (2007-11-14 12:04) [57]

Visual Basic надо учить. Ибо.

← →
Студент (2007-11-14 12:06) [58]

Да ацтой ваш delphi, у него кросс-платформенности нет. И шаблонов.

← →
Юрий Зотов © (2007-11-14 12:07) [59]

> Piter © (14.11.07 02:09) [46]

Миш, научись спорить конкретно. Или не спорь совсем.

Тебе приводят конкретные факты - а в ответ, извини, словоблудие. В лучшем случае - псевдоаргументы, к сути напрямую не относящиеся.

Несерьезно.

← →
Ega23 © (2007-11-14 12:10) [60]

> @!!ex © (14.11.07 07:42) [51]
>
> > [47] Германн © (14.11.07 02:16)
>
> Я думал я один такой... :)
> У меня до сих пор Д7.

У меня D7. И не стремлюсь менять.

← →
isasa © (2007-11-14 12:31) [61]

Студент (14.11.07 12:06) [58]

Да ацтой ваш delphi, у него кросс-платформенности нет. И шаблонов.

Ага, ага. А мы сразу пытаемся объять необъятное. Один раз написал и затих.
Универсальным только понос бывает ... :)

← →
isasa © (2007-11-14 12:34) [62]

Да, как всегда, забыл. А в универсальной Java когда речь заходит о соединении с сервером(да тем же браузером с бизнес слоем), так сразу универсальность пропадает и выясняется, что IBM сервера вижу, Sun Application Server не вижу.

← →
Azize © (2007-11-14 12:42) [63]

delphi - это хорошо
java -ещё лучше
Но самый крутой язык - Ассемблер
Порекомендуй преподу

← →
Marser © (2007-11-14 13:02) [64]

> boa_kaa © (14.11.07 11:56) [54]
> > Marser © (14.11.07 02:07) [44]> А недостатки, описанные
> ЮЗ - так > а разве в С# не та же история?Не та же. Причем
> совершенно не та же.

Весь внимание.

← →
TUser © (2007-11-14 13:03) [65]

А я вот думаю, что препод должен учить тому языку, который он сам знает в совершенстве. Потому что Delphi или Java могут быть хороши и замечательны, но нет ничего хуже препода, который в этом не разбирается. Может твой препод - Java-ас.

← →
Юрий Зотов © (2007-11-14 13:21) [66]

> TUser © (14.11.07 13:03) [65]

Если он Java-ас, то не разбираться в Delphi он просто не может.

← →
TUser © (2007-11-14 13:23) [67]

Также надо заметить, что у МС давно есть очень дешевые лицензии на VS для образовательных учереждений (гораздо дешевле борландовских). А Ява - всегда была бесплатной. И появление Turbo Delphi, разумеется, не означает мгновенного переписывания сложившихся программ ради такого хорошего Паскаля.

← →
DiamondShark © (2007-11-14 13:35) [68]

> Почему я и говорю - язык хорош для детского сада, но плох
> для профи.

Если "профи" определить как "лицо, склонное к половым перверсиям", то таки да, для такого язык типа Ц++ в самый раз. При развитой фантазии он и с Паскалем найдёт себе немало приятных минут.

А вообще, что вы хотите от жабы. Угребанская реализация стыренных у Вирта с Францем идей.

> Юрий Зотов © (13.11.07 22:22) [26]
>
> Пишем класс, наследник Object. В процессе своей работы класс
> захватывает некие ресурсы, отличные от памяти. Предлагается
> указать место, где класс должен эти ресурсы освободить.

А можно встречный вопрос: а где в описании языка написаны слова "автоматическое управление ресурсами, отличными от памяти"?

Метод Close и интерфейс IDisposable вам в руки.

> а ошибок управления памятью он уж как-нибудь и сам не допустит

ПлакалЪ.

Посмотрите любые списки уязвимостей, и сосчитайте количество дырок типа "arbitrary code execution".
Единственной причиной их наличия является то, что супер-пупер профи, пользуясь сами-знаете-каким языком для настоящих супур-пупер профи, "как-нибудь не допускают" ошибок управления памятью.

> DiamondShark © (14.11.07 13:39) [69]

1. А можно тоже встречный вопрос: а где я говорил об "автоматическом управлении ресурсами, отличными от памяти"? Говорилось как раз о ручном и предлагалось указать место, куда нужно прописать их освобождение. И... этта... нельзя ли читать повнимательнее?

2. Метод Close у класса Object я найти не смог (а мы писали потомок Object, напоминаю). И никакой другой метод класса Object, вызываемый перед разрушением объекта, я тоже найти не смог.

3. Насчет интерфейса IDisposable - метод Close я у него тоже найти не смог (есть метод dispose, который относится к классам графического интерфейса о котором см. ниже). Может, не в том интерфейсе искал? Можно привести его полное имя, вместе с пакетом? И если этот пакет - не java.lang.*, а любой другой, то еще пара встречных вопросов:

а. А где в описании языка упоминается интерфейс IDisposable?

б. Есть такой класс
public class MyObject /*extends Object*/ implements IDisposable { public void dispose() { ... } }
А есть гарантия, что метод dispose будет вызван перед разрушением объекта? Только прежде, чем отвечать, обратите внимание на предка.

> Юрий Зотов © (14.11.07 14:11) [71]

Метод Close надо написать ручками.
Не пойму, в чём проблема. Если вы работаете с unmanaged ресурсами, то и пишите их освобождатели сами, абсолютно точно так же, как в любом другом языке.

Не знаю как Юрий, но мне психологически трудно работать с ЯП с GC, жесткое правило старой закалки: создал - уничтожь, не дает покоя, дискомфортно как то себя чувствую :) что кто то за меня будет подбирать...
и привычка (может быть уже и вредная) освобождать внешние ресурсы именно в деструкторе, а не обвешивать логику класса двойной оберткой

конструктор
взятие ресурсов
освобождение ресурсов
деструктор

> DiamondShark © (14.11.07 14:30) [72]

Насколько я понимаю, вопрос в IDisposable отпал. ОК, идем дальше.

> Метод Close надо написать ручками.
Хоть тремя ручками - а вызывать его будет Пушкин?

> пишите их освобождатели сами
Не вопрос. А вызывать эти освобождатели будет тоже Пушкин?

> точно так же, как в любом другом языке.
А вот и не точно так же. В "другом" (известно, каком) языке у любого объекта есть деструктор, который гарантированно вызывается перед разрушением любого объекта и в котором я могу гарантированно освободить любые захваченные объектом ресурсы. А теперь (внимание, вопрос!) - покажите мне то место в любом объекте java, где я могу гарантированно освободить любые ресурсы, захваченные этим объектом, например, в своем конструкторе.

> Юрий Зотов © (14.11.07 14:50) [74]
> Насколько я понимаю, вопрос в IDisposable отпал

Неужели документация под руку попалась?

> ...Пушкин?
> ...Пушкин?

Вы объясните внятно, в чём суть претензии, и к кому/чему она адресована.

> и в котором я могу гарантированно освободить любые захваченные объектом ресурсы

Дык, а код освобождения в деструкторе за вас гарантировано напишет Пушкин?
Какая принципиальная разница, напишите вы этот код в деструкторе, или в спец. методе Close?

> мне то место в любом объекте java, где я могу гарантированно
> освободить любые ресурсы

IDisposable.dispose -- при попадании объекта под сборку мусора
Свой Close-подобный метод для детерминированного освобождения там где душа пожелает.

> DiamondShark © (14.11.07 15:05) [75]

> Неужели документация под руку попалась?

Нет, просто Вы проигнорировали оба моих вопроса по IDisposable и я это, естественно, понял так, что ответов на них у Вас нет.

> код освобождения в деструкторе за вас гарантировано напишет Пушкин?

Нет, Пушкин гарантированно вызовет деструктор. Большего от него и не требуется.

> IDisposable.dispose -- при попадании объекта под сборку мусора
> Свой Close-подобный метод для детерминированного освобождения
> там где душа пожелает.

Вот только что запустил Eclipse и попытался это сделать. Не получилось. Не могли бы Вы привести конкретный код непосредственного потомка Object, один из методов которого вызывается при попадании объекта под сборку мусора?

А я пока процитирую одну статеечку
( http://www.statmod.ru/3-5/programming/csharp_potapov/index.htm )
"Разработчики C# сочли этот метод настолько эффективным и удобным, что он поддерживается на уровне языка — посредством реализации интерфейса IDisposable. (Java такого механизма не имеет.)".

И задам вопрос - не путает ли кто-то из нас что-то?

а что тут спорить?
если "конечная цель" програмера сорваться на Запад, то Java ему очень
пригодится. :)

← →
Черный Шаман (2007-11-14 16:06) [78]

> Юрий Зотов © (14.11.07 14:11) [71]
>
> > DiamondShark © (14.11.07 13:39) [69]
>
> 1. А можно тоже встречный вопрос: а где я говорил об "автоматическом
> управлении ресурсами, отличными от памяти"? Говорилось как
> раз о ручном и предлагалось указать место, куда нужно прописать
> их освобождение. И... этта... нельзя ли читать повнимательнее?
>

Есть Object.finalize(), но он глючный

Вот только некоторые странные вещи, которые на первый взгляд могут не совпасть с нашим интуитивным представлением.

* Момент, когда вызовется метод finalize() четко не определен. На самом деле, в спецификации не гарантируется, что он воообще будет когда-нибудь вызван, даже если объект стал недостижим. Когда вызов может происходить зависит от реализации JVM.
* Метод finalize() не вызывает автоматически finalize() предка. Для того, чтобы это произошло, необходимо явно его вызвать: super.finalize().
* Метод finalize() будет вызван асинхронно, т.е. скорее всего в другом потоке. В текущей реализации Sun JVM для его обработки используется специальный поток "Finalizer", который последовательно вызывает финализаторы. Спецификация не ограничивает то, в каких потоках он может выполнятся или сколько может быть этих потоков. Единственное требование — это то, что этот поток не будет держать какую-нибудь блокировку. В одной из первых реализации JVM это разрешалось и приводило к странным эффектам.
* Ссылка на объект (this) доступна во время выполнения finalize(). Это означает, что потенциально объект может снова стать достижим. В этом случае метод finalize() никогда не будет вызван повторно.
* Объекты с нетривиальным методом finalize() обрабатываются сборщиком мусора особым образом. После того, как этот метод выполнился, сборщик мусора должен вновь определить что объект достижим. Это создает дополнительную нагрузку. Кроме того, в текущей реализации Sun JVM для поддержки используются дополнительные объекты FinalReference и Finalizer, что сказывается на объеме используемой памаять и производительности.
* То, что finalize() может исполняться в нескольких потоках параллельно, означает, что во многих случаях стоит позаботиться о синхронизации. В большинстве случаев нетривиальный метод finalize() будет использовать какие-либо разделяемые ресурсы.
* Порядок, в котором finalize() будет вызван не определен. Если у объекта A есть поле, которое ссылается на объект B и эти объекты стали недостижимы, то finalize() для A может быть вызван и до, после или одновременно с finalize() для B. Если B используется в finalize() для A, то его состояние во время выполнения не определено. Кроме того, это состояние может меняться во время выполнения finalize()!
* Спецификация не ограничивает, какие оптимизации могут применяться. Может так случиться, что finalize() будет вызван, после начала выполнения какого-либо метода, но но перед его завершением. Это иногда может стать проблемой, поскольку вызванный метод finalize() может невовремя изменить состояние поля объекта. Хорошим примером является 6295525.

> Есть Object.finalize(), но он глючный

Учитывая сказанное ниже, он не глючный. Он просто офигительно глюкавый!!!

Чтобы уж совсем разобраться в этом вопросе. В джаве все объекты имеют метод finalize, про который в доке сказано вот что: "Called by the garbage collector on an object when garbage collection determines that there are no more references to the object. A subclass overrides the finalize method to dispose of system resources or to perform other cleanup".

Казалось бы, это и есть то самое место, которое я просил показать. Однако же, не все так просто. Пишем примерчик:
public class DisposableObject { public DisposableObject() { super(); System.out.println("created"); } protected void finalize() throws Throwable { System.out.println("finalized"); super.finalize(); } }
И запускалку к нему:
public class Tester { public static void main(String[] args) { DisposableObject obj = new DisposableObject(); obj = null; obj = new DisposableObject(); obj = null; } }
И вот что имеем в консоли:
created created
и ни разу заветного слова finalized. О как! У GC, оказывается, своя логика.

Итак, мы выяснили, что метод finalize либо не вызывается совсем (что прямо противоречит документации и является вопиюще бездарным глюком), либо GC может вызывать finalize не сразу после обнуления счетчика ссылок, а когда сочтет нужным (но тогда, увы, толку от finalized немного - например, я хочу повторно открыть файл, а он еще не закрыт, оказывается, хотя должен был).

===========================

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

И другой вопрос - а если программа с аналогичными "закидонами" управляет рабочим местом диспетчера аэропорта, то чем виноваты пассажиры в лайнере?

delphi = pascal = языки для начинающих Найти похожие ветки