Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Куда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... Он что такой продвинутый что всем вынь да полож? Чем VB не угодил к примеру? Может потому что паскаль - язык студентов, коих и развелось пруд пруди? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 11:41 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Блинский блинКуда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... Он что такой продвинутый что всем вынь да полож? Чем VB не угодил к примеру? Может потому что паскаль - язык студентов, коих и развелось пруд пруди? Это значит, что будет кризис и у нас... В штатах так же, до кризиса был похожий взгляд на программирование. Дескать любая домохозяйка изучившая на коленке примеры с Явой - готовый кодировщик клиент-серверных решений. оказалось-не оказалось... с уважением (круглый) ЗЫ маятник. Я бы сказал по другому...Испытание популярностью не всегда приносит плюсы. Бывают и провалы. И они к сожалению чаще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 11:57 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
А можно по подробней, что за кризис в штатах такой был? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 12:27 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
wessenА можно по подробней, что за кризис в штатах такой был? 2001 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 12:33 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Блинский блин К сожалению, Борланд похоже решил, что не сможет конкурировать за серьезные ниши, и стал сдвигаться в нишу VB. Не знаю, как там обстоят дела, но не исключено, что VB в результате действительно откровенно вытесняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 13:28 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Блинский блинКуда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... Он что такой продвинутый что всем вынь да полож? Чем VB не угодил к примеру? Может потому что паскаль - язык студентов, коих и развелось пруд пруди? Где ты такое нашёл ?! :) Наиболее востребованные и интресные по зарплатам Java и с маленьким отрывом .NET :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 14:14 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Интегратор Delphi сейчас довольно плотно сел в нише, в которой раньше использовался VB: простенькие проекты на MSSQL. По моим ощущениям, предложений на VB последнее время действительно очень мало, хотя это - впечатления человека со стороны, который просто просматривает вакансии на этом форуме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 15:11 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Делфя штука удобная и хорошая. Но вот мёртвая правда. В том плане, что после 7.0 одно г... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 17:40 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
kolobok0 wessenА можно по подробней, что за кризис в штатах такой был? 2001 очень информативно... я оценил, спасибо. А почему не в двоичной системе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:42 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinДелфя штука удобная и хорошая. Но вот мёртвая правда. В том плане, что после 7.0 одно г... И кто тя в нее заставляет? По типу - мол, новое все круто? Напомню: - Работает? И больше НИ ЧЕГО НЕ ТРОГАЙ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
wessen kolobok0 wessenА можно по подробней, что за кризис в штатах такой был? 2001 очень информативно... я оценил, спасибо. А почему не в двоичной системе?посто сильно большой получится :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Radjamanпосто сильно большой получится :)имелось в виду пост ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 18:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Интегратор Блинский блинКуда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... Он что такой продвинутый что всем вынь да полож? Чем VB не угодил к примеру? Может потому что паскаль - язык студентов, коих и развелось пруд пруди? Где ты такое нашёл ?! :) Наиболее востребованные и интресные по зарплатам Java и с маленьким отрывом .NET :)Подписался. Имхо как раз .NET вытесняет Дельфи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 19:05 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
АборигенПодписался. Имхо как раз .NET вытесняет Дельфи. Я бы сказал, Борланд пытается втиснуть дельфу на то место, которое по идее должен был занять VB.NET. В результате для серьезных проектов она становится "мертвой", и уже в результате этого серьезные проекты уходят с нее. Лично я - люблю дельфу, но очень хорошо подумаю, прежде чем сейчас начинать на ней большой проект. Потому что сейчас она (в смысле, "серьезная дельфа") еще конкурентноспособна, но без развития через несколько лет будет занимать то же положение, что сейчас какая-нибудь Gupta или ABAP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 20:05 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Всё гавно, кроме Qt!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 20:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinВсё гавно, кроме Qt!!! Под Винду? Хм... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 20:47 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Di_LIne SarinВсё гавно, кроме Qt!!! Под Винду? Хм... А что мешает? Принципиально идеологический соображения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 20:51 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Sarin Di_LIne SarinВсё гавно, кроме Qt!!! Под Винду? Хм... А что мешает? Принципиально идеологический соображения? 1. Незнание, 2. Отсутствие лит-ры, 3. Стимула енто внедрять, 4. ... щас еще придумаю... Кароче! Не темни, а тынцым палец сделай... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 21:19 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
http://linuxcenter.ru/lib/books/qt3/qt3_7.phtml#CHAPTER3 Но там вся книга целиком. Просто это у меня открывалось в другой закладке. Ещё в нете её целиком найти можно. У меня есть. Но без картинок. Вот я на линуксцентр и полез. А ещё к КуТэ офигенная справочная система. Но на англицком. А ещё КуТэ очень проста и обеспечивает своего рода кроссплатформенность. А ещё в ней есть внутренняя красота и логичность. Попробуй. Это того стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 21:55 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Сенкс, Сарин... Но от слова "кросплатформенность" у меня колики животе начинаются... От смеха. Опять про "UNIERSALьный гаЯчный ключ" распространяться не бум. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 22:01 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Di_LIneСенкс, Сарин... Но от слова "кросплатформенность" у меня колики животе начинаются... От смеха. Опять про "UNIERSALьный гаЯчный ключ" распространяться не бум. Ты б сначала посмотрел, а потом будешь коликами хвастаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 23:34 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Кроссплатформенность в КуТэ это не то, что ты подумал. Никто не говорит, что спецефичные системные вызовы переписывать не придётся. Не придётся переписывать GUI. Ну и не ориентированный на систему код. Так как С два креста и в Африке С два креста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2005, 23:41 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinКроссплатформенность в КуТэ это не то, что ты подумал. Никто не говорит, что спецефичные системные вызовы переписывать не придётся. Не придётся переписывать GUI. Ну и не ориентированный на систему код. Так как С два креста и в Африке С два креста. Писать серьёзные бизнесс приложения сейчас на С++ ? Извините но это маразм. Нет достойного АПИ и скорость разработки роставляет желать лучшего. Я на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. Кстати по объявлениям по работе и месте С++/Java/.NET в современном мире всем чаще изучать RSDN :) ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 09:36 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Проекты пишутся для конечных пользователей. Поэтому, пока будет существовать парк винтел машин для этой платформы delphi будет именно универсальнейшим инструментом разработки. А насчет дотнет, ну выпустили пару неудачных продуктов. Так сразу сопли пускать чтоль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 10:32 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
wessenочень информативно... я оценил, спасибо. А почему не в двоичной системе? 2000 - 2001 года. это известная веха в штатах... кто работал в офшоре - тот в курсах... удачи Вам (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 12:33 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Интересно почитать про то, как "яблочники" победили проблему переноса исходников на MacOS(Intel). Говорят - очень красиво победили. И функции ядра как-то сохранили (или переписали уж не помню точно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 12:41 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinКроссплатформенность в КуТэ это не то, что ты подумал. Никто не говорит, что спецефичные системные вызовы переписывать не придётся. Не придётся переписывать GUI. Ну и не ориентированный на систему код. Так как С два креста и в Африке С два креста. Агась! Тогда, значится, и нуна указать ОБ каком програмерстве речь идет... А то всяк кулик в своем болоте нахваливается... Перед куличихами. ИНТЕГРАТОР - по теме указал. Да и ОПТИМИЦТ тож прав. ----------------------------------------------- А я, об енту крос-плять-форменность... Ну да... Про FB & YA говорю. Словал второй первого по Виндой... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 15:48 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Помедленнее пожалуйста! Я записываю. На выходных буду изучать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 15:58 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
ИнтеграторПисать серьёзные бизнесс приложения сейчас на С++ ? Извините но это маразм. Нет достойного АПИ и скорость разработки роставляет желать лучшего. Я на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. Кстати по объявлениям по работе и месте С++/Java/.NET в современном мире всем чаще изучать RSDN :) ! Что понимается под словом серьёзное бизнес-приложение? Интерфейс к БД? Так его хоть на ПХП написать мона. Может даж быстрей чем на делфе. А прикладную программу? Так её грех на Яве писать. И на дотнет. К дотнету у меня стойкая аллергия. Даж не знаю почему. Шумит мелкософт много. А когда много шумят значит пытаются фуфло втюхать. Хороший продукт (типа КуТэ) за себя сам говорит. Труд программистов уже скока временни оптимизировать пытаются? Жаба, дотнет, питон. Все они ни шага вперёд больше не сделают. В ближайшие 20 лет (если не родится квантовый компуктер) большинство программ будут писаться на С/С++. И ничего другого, столь же универсального, на смену не придёт. Могу забится. Идеология программирования для Линукс позволяет быстро и качественно писать прогу. Вам не приходится каждый раз переделывать труд других программистов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 17:55 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Sarin ..Идеология программирования для Линукс позволяет быстро и качественно писать прогу. Вам не приходится каждый раз переделывать труд других программистов. . Понравился твой прогноз на квантовые компутеры. И причинно следственная связь между шумом и втюхиванием фуфла - тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 18:24 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
ИнтеграторЯ на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. Угу. Гораздо интереснее искать, где именно не был убит указатель на подвисший объект, или - что более интересно - давно убитый объект, висящий на WeakReference, вдруг оживает :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 19:07 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinВ ближайшие 20 лет (если не родится квантовый компуктер) большинство программ будут писаться на С/С++ Я почти уверен, что 20 лет назад без проблем услышал бы подобный прогноз в отношении Fortran-а, тем более как раз готовилась его новая версия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 19:10 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinИдеология программирования для Линукс позволяет быстро и качественно писать прогу. Вам не приходится каждый раз переделывать труд других программистов. Постойте-постойте уважаемый... Десктопы, хоть убейся, а еще лет 20, под Виндами разными будут... Забьемся? Ты свой 20 - я свой... И уж Борланд скорей среагирует на ПримНамВсемБаски МелкоМягкого... имхо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 19:14 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarerЯ почти уверен, что 20 лет назад без проблем услышал бы подобный прогноз в отношении Fortran-а, тем более как раз готовилась его новая версия. А что, фортран больше не применяется? Я про фортран слышу регулярно. Но, к сожалению, он расчитан на математиков. А прикладное программирование пошло по пути С. И только борланд (отдадим ему должное) попытался бросить вызов и выпустил Делфи. Продукт был удачным. Но у борланда что-то случилось с "самым умным парнем". Может с катушек слетел. Но попытка выпустить Делфю под дотнет, фактически, успехом не увеньчалась. Ублюдки типа сишарпа это языки того же уровня, что и питон. У них есть круг(!!!) применения и круг любителей. Так же как и у паскаля, и у явы. Но если можно с чистой совестью судить о таких языках категориями нравится/ NOT нравится, то к Си эти понятия не применимы. Это почти так же, как сказать что мне не нравятся команды процессора. Я поставил три восклецательных знака у слова "круг" по той простой причине, что круг использования С почти (мне, лично, исключения не встречались; но на всякий случай почти) полночтью соответствует области применения цифровых (а есть ещё и аналоговые) вычислительных устройств. По поводу шума и фуфла: эта тенденция очь хорошо видна в ВПК. Примеры: F-22 и новая штатовская штурмовая винтовка (вроде XM-29). Di_LIneДесктопы, хоть убейся, а еще лет 20, под Виндами разными будут... Забьемся? Ты свой 20 - я свой... И уж Борланд скорей среагирует на ПримНамВсемБаски МелкоМягкого... имхо. А какая связь между виндой и С? Ты про то, что Борланд будет продолжать линейку безвременно казнённой делфи? Так ты знаешь, какая популярность у сего продукта в США и Европе? По поводу винды: её доля будет медленно но верно сокращаться. Лонгорог, судя по всему, стратегическая ошибка мелкомягких. Посмотрим, что будет после него. Но в любом случае лонгорог - технологический застой. Линуксоиды скоро выйдут на ядро 3.0 В любом случае раньше, чем выйдет второй сервиспак к лонгорогу. Практика перевода ПО на юниксовые рельсы показала их целесообразность. Речь в частности о CorelDraw. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 20:16 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Sarin ..Ублюдки типа сишарпа это языки того же уровня, что и питон.. Читая ваши посты у меня складывается впечатление, что вы не знакомы с C# . А посему предлагаю свернуть флейм Windows-VS-ЧтоНибудь и продолжить обсуждение разработок Borland-a. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 20:36 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
maytonЧитая ваши посты у меня складывается впечатление, что вы не знакомы с C# . А посему предлагаю свернуть флейм Windows-VS-ЧтоНибудь и продолжить обсуждение разработок Borland-a. Нет. Не знаком. Но рискну кинуться утверждением, что язык заточенный под конкретную ОС и конкретную виртуальную машину мёртворождённый по дефолту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 20:41 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Борланд привязан к Винде. Куликс провалился. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2005, 20:43 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Sarin maytonЧитая ваши посты у меня складывается впечатление, что вы не знакомы с C# . А посему предлагаю свернуть флейм Windows-VS-ЧтоНибудь и продолжить обсуждение разработок Borland-a. Нет. Не знаком. Но рискну кинуться утверждением, что язык заточенный под конкретную ОС и конкретную виртуальную машину мёртворождённый по дефолту. Аргументы, плиз! Тем более, что: SarinБорланд привязан к Винде. Куликс провалился. ... противоречишь сам себе. И так, попробую дать свой расклад: 1. ДескТоп - Винды, во всех видах и позишенах ( ) 2. Заказчик - из расейской глубинки. (Со всеми выткающими и... втекающими. ) 3. Услоия работы софтинки - 24х7. 4. Наши дополнения к ТЗ: - минимум "сопровождения", - минимальные сроки реализации, - .... (тут каждый добавит от себя) И так вопрос: - На чем ето писать? Пишем на D6, так как в ейных модулях, за это время, успели пофиксить и попатчить кучку нюансов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 12:01 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Di_LIne Пишем на D6, так как в ейных модулях, за это время, успели пофиксить и попатчить кучку нюансов... Я подпешусь. Так как сам бы выбрал Делфи. Только седьмую. Но время идёт. Старые продукты морально устаревают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 12:53 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinНо время идёт. Архумент принимаю! Sarin Старые продукты морально устаревают. И в чем эта мораль? арХументы типа: Круто, Модно и т.п. - ВЗАТчет не принимаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 13:22 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Sarin ИнтеграторПисать серьёзные бизнесс приложения сейчас на С++ ? Извините но это маразм. Нет достойного АПИ и скорость разработки роставляет желать лучшего. Я на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. Кстати по объявлениям по работе и месте С++/Java/.NET в современном мире всем чаще изучать RSDN :) ! Что понимается под словом серьёзное бизнес-приложение? Интерфейс к БД? Так его хоть на ПХП написать мона. Может даж быстрей чем на делфе. А прикладную программу? Так её грех на Яве писать. И на дотнет. К дотнету у меня стойкая аллергия. Даж не знаю почему. Шумит мелкософт много. А когда много шумят значит пытаются фуфло втюхать. Хороший продукт (типа КуТэ) за себя сам говорит. Труд программистов уже скока временни оптимизировать пытаются? Жаба, дотнет, питон. Все они ни шага вперёд больше не сделают. В ближайшие 20 лет (если не родится квантовый компуктер) большинство программ будут писаться на С/С++. И ничего другого, столь же универсального, на смену не придёт. Могу забится. Идеология программирования для Линукс позволяет быстро и качественно писать прогу. Вам не приходится каждый раз переделывать труд других программистов. Видите ли, при определённом опыте программирования на самом деле на каком языке писать совершенно не принципиально в некоторых пределах :) Намного важнее АПИ, доступное на этом языке, средства автоматизации создания приложения, поддержка со стороны поставщика (дабы не влипнуть через 5 лет когда язык по сути перестанут развивать) и поддержка со стороны платформы, позволяющая делать меньшими силами более надёжное приложение. Вы скажете что это приводит к неоээфетивному коду ? Знаете, отчасти вы правы, но намного важнее для заказчика чколько денег он вложит в разработку и сколько времени пройдёт до запуска приложения, чем те миллисекунды которые вы выиграете при использховании более ручной работы. Да, есть приложение где это критично - и там заказчит БУДЕт за это платить, так как это требует рынок. Серьёзные приложения - это приложения которые реализуют сложную бизнес- логику, допускают расширение и находятся в активном использовании. Если вы собрались сейчас писать приложения автоматизации какого нить документооборота или бух учёта, или систему бронирования билетов в аэропорту на С++ - ваш проект обречён умереть :). Ну если конечно вы не готовы неоправдано вбухивать деньги. Выбирать надо то что наиболее подходит под конкретную задачу а не фанатично делать так как вы привыкли или вам просто нравится. А про идеологию Линукс - извинити, но это просто десткий сад :) Самому не смешно ? Во всяких дичскусиях типа винда - остой, ЛИНУХА СУПЕР не учавствую :) Мне платят за работу в винде, найти заказ под линуху сложнее, мне нравится работать в студии и ворде, под линуху мне не комфортно, никаких пристрастий, если завтра мне предложат больше за линуху буду работать на линухе :) Хотя дома всё равно винда мне приятнее ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 16:04 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinА что, фортран больше не применяется? Наверное, применяется. Но "большинство программ будет написано" для него неактуально. SarinНо, к сожалению, он расчитан на математиков. Чем это? Были версии, где в язык были вставлены, например, массивно-параллельные вычисления - и что с того? У меня супруга писала диплом на массивно-параллельном C - но это же не повод говорить, что C рассчитан на математиков :) "Математичность" фортрана - это не то что легенда, это историческая шутка. Фортран - предок бейсика, первый из проектов ряда "давайте программировать без программистов"; соответственно математики широко пользовались им, понаписали библиотек... через несколько лет для тех, кому был слишком сложен даже фортран, придумали кобол :) SarinА прикладное программирование пошло по пути С. Причем достоинства языка тут, вообще говоря, не при чем. Я помню время, когда "оно пошло" - это была мода, такая же, как спустя десять лет мода на java, например. SarinИ только борланд (отдадим ему должное) попытался бросить вызов и выпустил Делфи. Ээ... это очень краткое изложение истории. Вы практически одним махом выбросили 10 лет, с 85-го по 95-й годы :) Если рассматривать историю, то получится примерно так: был Microsoft с компиляторами Microsoft C, Quick C, Microsoft Pascal и Quick Basic. Был Borland с продуктами Turbo C, Turbo Pascal и Turbo Basic. Ну и были прочие производители, в основном с C - Zortech, Lattice, Watcom, еще кто-то. В этом противостоянии Microsoft имел несколько лучший компилятор C и много худший компилятор паскаля. Соответственно, Quick C и Microsoft Pascal почили в бозе и Microsoft начал давить своим лучшим продуктом - Microsoft C - одновременно поддерживая бейсик "для полноты линейки". И занял очень выгодную позицию, поскольку именно что начиналась мода на С (которую он, само собой, поддержал); именно тогда появилась прорва народа, оравших что-то типа "С - это круто, все прочее - отстой". Борланд оказался в цугцванге. Он похоронил Turbo Basic, но все равно ему было тяжело, поскольку как компилятор Turbo/Borland C был хуже, а у флагманского продукта - паскаля - почва явно уплывала из-под ног. К середине девяностых перед борландом замаячило банкротство, но он сумел сделать гениальный финт и выпустить Delphi; за год-полтора борланд превратился из затухающей звезды почти в тот стартап с блестящим будущим, каким был в начале восьмидесятых. Ну а дальше - дальше Microsoft продолжал давить по выбранной линии и постепенно пришел к той же ситуации, которая сложилась году в 93-м. В чем ошибка борланда - не знаю. Мне кажется, что он все время излишне разбрасывался; на C++Builder, потом на Java Builder, на прочие проекты, и в результате больше ничего не делал действительно хорошо. Не исключено, что им стоило сразу забить на свой компилятор C - но не знаю, вряд ли возможно судить со стороны. Вот, собственно, история "выбора C для прикладного программирования". SarinПродукт был удачным. Но у борланда что-то случилось с "самым умным парнем". Может с катушек слетел. Вроде как в Microsoft ушел. Sarinто к Си эти понятия не применимы. Это почти так же, как сказать что мне не нравятся команды процессора. Для начала стоит отличить Си и Cи++. Последний мне лично именно что не нравится - потерявший хорошие черты Си и давший весьма плохие собственные. Кстати, его успех - как раз тот случай, когда победил продукт, выпущенный первым, в то время как куда лучше проработанные еще пребывали в альфа-стадии, где в итоге и остановились. SarinПо поводу винды: её доля будет медленно но верно сокращаться. Такие прогнозы я слышу примерно со времени выхода MS-DOS 3.0 :) Пока что все победы над мелкософтом, которые я видел, были сугубо временными. Конкретно линукс - слишком любительская и наколеночная поделка, чтобы его можно было считать блестящим будущим ИТ. Мелкософт применяет свою обычную тактику: берет хорошие идеи из того же линукса и с оставанием в версию-две качественно их реализует. Не думаю, что эта позиция вдруг станет неуспешной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 17:30 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer "Математичность" фортрана - это не то что легенда, это историческая шутка. Фортран - предок бейсика, первый из проектов ряда "давайте программировать без программистов"; соответственно математики широко пользовались им, понаписали библиотек... Чушь, не было такого. Программирование для домохозяек это лозунг нового времени, когда создавался фортран такая чепуха никому в голову не могла прийти. Язык создавался чтоб избавить пишущего программу специалиста (математика, физика, химика) от необходимости изучать конкретный процессор и позволить ему обходиться без непосредственного участия СИСТЕМНОГО программиста. Цель была достигнута. Фортран и сейчас интенсивно используется в своей области и ничего более удобного для флоат вычислений все еще не придумали. softwarer через несколько лет для тех, кому был слишком сложен даже фортран, придумали кобол :) Только непонятно каким боком финансовый кобол стоит к флоат-вычислениям, на которые заточен фортран. Решение систем интегродифференциальных уравнений в бухгалтерии вроде бы пока не используется. softwarer Причем достоинства языка тут, вообще говоря, не при чем. Я помню время, когда "оно пошло" - это была мода, такая же, как спустя десять лет мода на java, например. Ошибаетесь, это ложная память. С занял первое место гораздо раньше чем за 10 лет до повальной моды на джаву, серьезный взлет которой начался в районе 1995-го года. В 80-м году альтернативы С в системном программировании в серьезных ОС уже не было, только машинно зависимый ассемблер, а то что к этому идет стало ясно еще раньше, с успехом юникса. Если Вы судите по ДОС-у, то он серьезной ОС не считается по понятным причинам. softwarer В этом противостоянии Microsoft имел несколько лучший компилятор C и много худший компилятор паскаля. Компилятор был далеко не лучший. Например долго не было 32-х разрядного компилятора а у конкурентов был. Оболочка была лучше чем у тех, у кого был лучший компилятор и маркетинг был лучший. А у борланда оболочка была лучше, но компилятор хуже и маркетинг хуже. А выигрывает маркетинг и красивая морда. softwarer Такие прогнозы я слышу примерно со времени выхода MS-DOS 3.0 :) Пока что все победы над мелкософтом, которые я видел, были сугубо временными. Ну кое-где мелклософт до победы еще не дорос и уже не дорастет. К тому же Билли стареет, раньше он был молодой и горячий, а самое главное - сам всем руководил. Теперь руководят другие, не такые умные, а БГ только присматривает за основными направлениями. А М$ - компания одного человека, и без этого не работает. В результате в М$ бардак, никто не знает что делает соседний отдел, поддерживается миллион разных прдуктов купленных у разных производителей и чем дальше тем хуже. Уже все начинает потихоньку осыпаться. А тут еще конкуренты типа линкуса сделанного на коленке и почему-то оказавшегося гораздо надежнее вынды, вдруг отвоевывают по пол-рынка в некоторых областях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2005, 23:55 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127К тому же Билли стареет, раньше он был молодой и горячий, а самое главное - сам всем руководил. Теперь руководят другие, не такые умные, а БГ только присматривает за основными направлениями. Зато столько народу сидит на его игле, что другим и не снилось. Интуитивно понятный интерфейс (и, возможно, красивый) - еще тот наркотик. Там это быстро усвоили. c127никто не знает что делает соседний отдел Когда отделов более, чем два, то запросто. c127результате в М$ бардак Слишком сильное утверждение - чтобы говорить так, надо, по крайней мере, там работать. c127А тут еще конкуренты типа линкуса сделанного на коленке и почему-то оказавшегося гораздо надежнее вынды, вдруг отвоевывают по пол-рынка в некоторых областях. Ключевое слово здесь - "в некоторых". А что касается надежности - беда майкрософта, что они сами для себя железо не делают. И что позволяют ставить на свою ось драйвера левых производитлей. SarinНо попытка выпустить Делфю под дотнет, фактически, успехом не увеньчалась. Однозначно. Причем в потугах наблюдается некая поспешность. Неужто майкрософт всех напугал, что в след. винде будет работать только управлемый код? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 01:55 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей Алексеевич. А что касается надежности - беда майкрософта, что они сами для себя железо не делают. И что позволяют ставить на свою ось драйвера левых производитлей. ussssssssssssssssssssssssss ой гыыыыыыы простите не удеражался. нехай мс делает железо и непускает драйвера сторонних это будет их капец. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 03:08 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer "Математичность" фортрана - это не то что легенда, это историческая шутка. Фортран - предок бейсика, первый из проектов ряда "давайте программировать без программистов"; соответственно математики широко пользовались им, понаписали библиотек... фортран далеко не предок бейсика. в версиях бейсика в 98 - 90 годы небыло функций с формальными параметрами. а у фортрана они были изначально. и никогда в фортране не нумеровались строки, как бейсиках ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 03:14 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
> и никогда в фортране не нумеровались строки, как бейсиках ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 03:47 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingiz Гавриленко Сергей Алексеевич. А что касается надежности - беда майкрософта, что они сами для себя железо не делают. И что позволяют ставить на свою ось драйвера левых производитлей. ussssssssssssssssssssssssss ой гыыыыыыы простите не удеражался. нехай мс делает железо и непускает драйвера сторонних это будет их капец. А никто и не спорит. Вряд ли их закидают камними за ненадежность ( некому будет ?), но пользовать их будет столько же процентов народа, сколько и маки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 07:09 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 07:34 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer Для начала стоит отличить Си и Cи++. Последний мне лично именно что не нравится - потерявший хорошие черты Си и давший весьма плохие собственные. softwarer я тебя все больше и больше уважаю. softwarerчерез несколько лет для тех, кому был слишком сложен даже фортран, придумали кобол :) Но с этим согласен не до конца. Кобол очень сложен, гораздо сложнее Фортрана. softwarerТакие прогнозы я слышу примерно со времени выхода MS-DOS 3.0 :) Все-таки с Лонгхорном и Юконом они на мой взгляд конкретно облажались. Кроме того, ВСЕМ хочется верить в это :) Проблема в другом, сколь бы не был плох Microsoft, заменить его НЕКОМУ. softwarerлинукс - слишком любительская и наколеночная поделка Согласен, но в последнее время, Linux весьма не плох (и становится все лучше), а после того как Oracle обратил на него внимание, у него появилась весьма достойная область применения. Кроме того, огромное количество ностальгирующих юниксоидов тоже не стоит сбрасывать со счетов. Ну и наконец, Linux попортил немало крови Microsoft (читай, создал здоровую конкуренцию). Одно это УЖЕ хорошо. P.S. Правда, в последнее время, я стал замечать, что Торвальдс на фотографиях все больше и больше становится похож на Гейтса (на фотографиях же). Но может быть, мне это просто кажется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 08:36 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127В 80-м году альтернативы С в системном программировании в серьезных ОС уже не было, только машинно зависимый ассемблер, а то что к этому идет стало ясно еще раньше, с успехом юникса. Если Вы судите по ДОС-у, то он серьезной ОС не считается по понятным причинам. softwarerДля начала стоит отличить Си и Cи++. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 08:42 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Красивый и удобный интерфейс - наркотик, на котором и я в том числе сижу. И когда мне приходится вместо красивого и удобного KDE пользоваться как из топора вырубленным Експлоррером у меня случается ломка. KDE более требователен к ресурсам. Но это, в принципе, решаемо. У меня на Матроксе Ж450 он, конечно, не летает. Но работать вполне комфортно. KDE логичен во всём почти. Это система значительно более высокого уровня, чем Експлоррер. Будущее Линукса сейчас гарантированно в первую очередь поддержкой ИТ-монстров типа IBM. Они обеспечивают "маркетиноговую атаку" не желая мирится с господством мс. И будущая (я уверен) популярность Линукса обеспеченна не его приемуществом, а этой самой поддержкой. Которая может, в принципе, ничего кроме рекламы и не делать. Я, лично, являюсь сторонником господства закрытой операционной системы. Типа винды. Мс мне противна. Но её могущество обеспечивает сущесствование братства (не побоюсь этого слова) приверженцев открытых лицензий. Как только линукс станет настолько популярным, что большинство ИТ-компаний будут выпускать свои продукты под него он перестанет быть оплотом открытых исходников. И что тогда будет я предположить не могу. Возможно, крупные компании начнут с каждым своим продуктом (ну типа фотошопа) выпускать свой дистрибудив. Представьте себе такой дистрибутив от Adobe: вставляете диск. Перезагружаетесь. Запускается установщик. Вы сначала соглашаетесь с лицензией GPL, потом с лицензиями на адобовские продукты. И в итоге получаете систему сразу с шопом, премьером, писалкой PDF, лингво и парой книжек электронных в нагрузку. Di_LIne арХументы типа: Круто, Модно и т.п. - ВЗАТчет не принимаются. А нахрена тебе тогда делфя шестая? Пиши под консоль. К счастью, такие аргументы не применяются в Линухе. К сожалению, без них не обойтись тем, кто пишет за деньги. softwarerКонкретно линукс - слишком любительская и наколеночная поделка, чтобы его можно было считать блестящим будущим ИТ. Мелкософт применяет свою обычную тактику: берет хорошие идеи из того же линукса и с оставанием в версию-две качественно их реализует.Наколеночная? Что тебе кажется в нём наколеночным и поделочным? У меня создалось впечатление, что стандартная тактика мелкософта такая: берётся хорошая идея А. Всеми правдами и неправдами втыкается в продукт Б. Пока программисты ломают голову над тем, как идею А можно применить в продукте Б маркетологи орут о том, что хорошо себя зарекомендовавшая идея А нашла новое применение в продукте Б, бетаверсия которого скоро будет распространена среди тестеров. Программисты в это время находят как А присовокупить к Б. Но вот незадача: А надо чуток изменить. Маркетологи начинают орать про идею С: A new Abased tecknology C is used in produckt B. Но тут возникает новая трудность. Оказывается приживление приводит к тому, что Б безбожно лагает и рушится. В виде бесплатного дополнения он ещё и систему сносит иногда. Сроки здачи откладываются. Маркетологи не дремлют. Они договариваются с партнёрами о поддержке Б. Программисты тем временнем доводят Б до работоспособного состояния и выбрасывается на рынок. Юзеры кидаются покупать не успев залезть в нэт и почитать маты тех счасливчиков, которые уже успели купить. А когда партнёры начинают выпускать продукты, которым для работы необходим Б покупать приходится даже тем неторопливым, которые успели прочитать отзывы. Разумеется, картина слегка утрированна. Но примеров испаганивания технологий тьма. Первый пример пришедший на ум CORBA и COM. COM, лично мне, очень понравился. Но с корбой я не работал. А если послушать тех кто может сравнивать, так мелкософт только "ненужные" функции убрал. Хочу напомнить, что мс участовоал в разработке CORBA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 20:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
\\ Сарин. Ты все в кучу не сваливай... КДЕ тут при чем и прочая ЁксИхПлорера??? авторБудущее Линукса сейчас гарантированно в первую очередь поддержкой ИТ-монстров типа IBM. Ага... Только посмотри назад и скажи: - Сколько проетов БиБиЁм начинала и... Сколько их них успешно почили в бозе. OS/2, DOS на какой стадии они бросили? Выкупали перекупали проекты, не зная потом куда их деть... Если не ошибаюсь, то история с "ВордПерфект" - очень показательна. Настольные ПК их где? А были времена "IBM-совместимый"... С винтами от БиБиЁм тоже поговорим... Что еще забыл? Щас напомнят... А нахрена тебе тогда делфя шестая? Пиши под консоль. А стоило ерничать? Настроение у тебя плохое. "Наступили", что-ль, где-то на тебя? Да хоть под "Монитор" для РК-86 или "Иришу", ДВК-ашу... - Это уж дело заказчика... К счастью, такие аргументы не применяются в Линухе. К сожалению, без них не обойтись тем, кто пишет за деньги. Оп-с!!! Народ чичас разбогатеем!!! Помните Сарин програмку распространял: - Хайло Ворлд? Ну... Думаю по 10$ будет не дорого, за ее икс-плуатацию. Мне - телеграфирую перевод: - Деревня, Дедушке. А про маркетологв ты по сути прав, а не по приведенным фактам и идеям. Их, маркетоголов, задача: - Создать(!!!!!!!!!!!) рынок сбыта. Вот тебе пример: - Как можно было эскимосов Гренландии заставить покупать перец? А ведь покупают теперь... И едят с ним ижить без него не могут. А про "дрист-рибутивы" Линуха ты что ж не сказал? Или считаешь что так и пральна? Но.. - У семи нянек - дитя без глазу. Вот это и будет логичный конец Линуха... Хотя ты Я, лично, являюсь сторонником господства закрытой операционной системы. Так как же так??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 20:54 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Ты с теорией хаоса знаком? Коммунить вокруг Линуха - устойчивый аттрактор. Он может существовать БЕЗ руководителя и БЕЗ потпитки из вне. Этого нельзя сказать про мс. Без Билла она - ничто. IBM просрала много чего. Но IBM, пока по крайней мере, сила с которой нельзя не считаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 21:54 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
SarinТы с теорией хаоса знаком? Не-а... И что, есть реальные финансовые проекты построенные на ее основе? SarinКоммунить вокруг Линуха - устойчивый аттрактор. Он может существовать БЕЗ руководителя и БЕЗ потпитки из вне. Этого нельзя сказать про мс. Но... Как средство ИЗВЛЕЧЕНИЯ доходов - ни фига. Только не нужно грить о тех суммах, что есть сейчас. Сравни их с М$-ными... SarinБез Билла она - ничто. А тут уточни, о чем ты? О лице физическом - по имени Билл Шлюз, или о синониме "Билл Гейтс== корпарацияМикроСофт"? Если о первом - пример Пьера Кардена очень показателен. Да и во воторм тож применим. Так, как работает команда хороших профи... Интересно, а ты задавался когда-либо вопросом: - А что, МС только софтом занимается? Давно известно, что хранить все яйца в одной корзинке не умно... Sarin IBM просрала много чего. Но IBM, пока по крайней мере, сила с которой нельзя не считаться. Во! Эт другое дело! Речь Мужа, а не мальчика. И ее сила, имхо, не в области софтвера лежит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 22:06 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Софт с железом, как и инь с янем:) Линух в первую очередь не коммерческий проект. Но маааааааааленький некоммерческий проектик фаерфоксик МСу уже не мало крови попортил. И всяк, кто не хочет плясать под дудку МС (из компаний) ударяется в Линух. За редким исключением в БСД. Что IBM ставит на свои сервера? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 22:52 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Оптероны) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2005, 23:30 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) c127В 80-м году альтернативы С в системном программировании в серьезных ОС уже не было, только машинно зависимый ассемблер, а то что к этому идет стало ясно еще раньше, с успехом юникса. Если Вы судите по ДОС-у, то он серьезной ОС не считается по понятным причинам. softwarerДля начала стоит отличить Си и Cи++. Да, согласен, не в тему, речь шла о Cи++. Но первый пост был все-таки о С: Sarin> то к Си эти понятия не применимы. Это почти так же, как сказать что мне не нравятся команды процессора. Я на него и повелся. Гавриленко Сергей Алексеевич Зато столько народу сидит на его игле, что другим и не снилось. Интуитивно понятный интерфейс (и, возможно, красивый) - еще тот наркотик. Там это быстро усвоили. Ну не только там, макинтоши это сделали гораздо раньше и сейчас лидируют. Мне их интерфейс не понравился, но те кто работает и там и тут говорит что макинтошевский интерфейс гораздо удобнее винды. Линух с БСД догоняют, иксы можно настроить так что от винды не отличишь. Немного подогнать средства типа Кдевелопера и все. Хотя командная строка ИМХО удобнее. Гавриленко Сергей Алексеевич c127никто не знает что делает соседний отдел Когда отделов более, чем два, то запросто. Пока Билли был у руля такого не было. Я о том и говорю, что мелкософт поднялся иключительно благодаря гению БГ, кроме этого там ничего нет, ни каких-то значительных технологий, ничего. А гений потихоньку сваливает. Гавриленко Сергей Алексеевич c127результате в М$ бардак Слишком сильное утверждение - чтобы говорить так, надо, по крайней мере, там работать. Не надо, иногда достаточно пообщаться с людьми которые там работают, с саппортом пообщаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 01:40 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Di_LIne Интересно, а ты задавался когда-либо вопросом: - А что, МС только софтом занимается? Давно известно, что хранить все яйца в одной корзинке не умно... Возможно, но самое глваное это то что БГ занимается не только мелкософтом, причем мелкософтом он похоже занимается все меньше и меньше. Бабки вытаскивает, так как, совершенно верно замечено, все яйца в одну корзину складывать не умно. Чует куда ветер дует. ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 01:47 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Все это не изменит одного простого факта. Нишу Микрософт на сегодняшний день заполнить НЕКОМУ. Поэтому она может загнивать до опупения, а мы будем продолжать под нее прогибаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 08:24 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127Возможно, но самое глваное это то что БГ занимается не только мелкософтом, причем мелкософтом он похоже занимается все меньше и меньше. c127, просвети пожалуйста - чем же еще таким занимается БГ, отдавая ентому занятию все больше времени в ущерб Майкрософт? Может, тайно учайствует в разработке того же Linux али же на кухне Sinclair-ы паяет по ночам? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 10:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Дык и далеко ходить не надо... http://news.proext.com/money/17951.html http://www.dn.kiev.ua/business/world/mikr11.html А вообще, поройся в тыр-нете, это уже с 200-го года, тенденция однако. В то-же время БГ скупал акции SAP. Пытался покупать даже акции Оракуля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 11:20 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Очепятался, с 2000-го года... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 11:23 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
авторНу не только там, макинтоши это сделали гораздо раньше и сейчас лидируют. Мне их интерфейс не понравился, но те кто работает и там и тут говорит что макинтошевский интерфейс гораздо удобнее винды. У тех, кто сидит на маках отношение к майкрософту, если мягко сказать, пренебрежительное, это факт. Что касается интерфейса - вполне возможно, он точно не хуже. Но мак берет не этим, они всё-таки понадежнее писюков (гы, так их и называю) будут. Не из-за одних же красивостей и удобностей оси за железку в два раза больше платят? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:00 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127Программирование для домохозяек это лозунг нового времени, когда создавался фортран такая чепуха никому в голову не могла прийти. Именно. В те времена был лозунг "программирование для математика/физика/химика..." Та же самая "чепуха", вид сбоку. c127Фортран и сейчас интенсивно используется в своей области и ничего более удобного для флоат вычислений все еще не придумали. Зависит от. Возможно, я отстал от жизни, но ничего "специфически удобного" в этом языке я не назову; он просто что успел обрасти отлично отработанными библиотеками. Впрочем, для Wintel-платформы я бы наверное таки выбрал Intel C, благо конверторы фортрана в C давным-давно существуют, а оптимизация все-таки на другом уровне. c127Ошибаетесь, это ложная память. С занял первое место гораздо раньше чем за 10 лет до повальной моды на джаву, серьезный взлет которой начался в районе 1995-го года. В 80-м году альтернативы С в системном программировании в серьезных ОС уже не было, А с какого бока Вы приплели сюда системное программирование? Утверждение моего оппонента, на которое я отвечал, касалось прикладного программирования. История здесь повторилась. Когда появились ЯВУ и стали программировать те самые предметники без глубоких знаний ЭВМ, появилась тенденция, с которой боролись добрых двадцать лет - ассемблерные программисты считались более компетентными просто потому, что они программировали на ассемблере. Сначала, наверное, это так и было, но потом появился слой более чем компетентных прикладников, которые, однако, ценились не так высоко как посредственные ассемблерщики. Не успели закончиться подобные споры, как появился системный Си, добился своего заслуженного места, и начались такие же крики типа "Си - немеряный рулез", пошла точка зрения "крут только потому, что программирует на Си" и на Си стали активно разрабатываться прикладные программы. c127Компилятор был далеко не лучший. Лучший. Microsoft C регулярно выигрывал в различных замерах на эффективность генерируемого кода. В отдельных тестах вперед вырывались другие, но в целом он держал первое место; борландовский компилятор в разговорах позиционировался как "не слишком хуже, но с IDE". c127Например долго не было 32-х разрядного компилятора а у конкурентов был. К моменту появления 32-битных компьютеров борланд уже проиграл, и это мало что могло изменить. c127Оболочка была лучше чем у тех, у кого был лучший компилятор и маркетинг был лучший. Какая оболочка? У Microsoft C не было оболочки, он был command line-овый. Его оболочка называлась Quick C; предполагалось, что программист сначала в этом IDE набивает-отлаживает, а потом компилируется Microsoft C и получает эффективный продукт. c127А у борланда оболочка была лучше, но компилятор хуже и маркетинг хуже. А выигрывает маркетинг и красивая морда. В данном случае выиграл правильный маркетинг. Microsoft сначала привлек к себе профессионалов - своим компилятором. Потом дорисовал студию, и ей в сочетании с примером профессионалов привлек остальных. А борланд остался с посредственным компилятором и устаревшим IDE. C++Builder - сомнительная попытка с сомнительным же успехом. Насчет прогнозов мрачного будущего MS - скажем так: поживем - увидим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:01 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127Программирование для домохозяек это лозунг нового времени, когда создавался фортран такая чепуха никому в голову не могла прийти. Именно. В те времена был лозунг "программирование для математика/физика/химика..." Та же самая "чепуха", вид сбоку. c127Фортран и сейчас интенсивно используется в своей области и ничего более удобного для флоат вычислений все еще не придумали. Зависит от. Возможно, я отстал от жизни, но ничего "специфически удобного" в этом языке я не назову; он просто что успел обрасти отлично отработанными библиотеками. Впрочем, для Wintel-платформы я бы наверное таки выбрал Intel C, благо конверторы фортрана в C давным-давно существуют, а оптимизация все-таки на другом уровне. c127Ошибаетесь, это ложная память. С занял первое место гораздо раньше чем за 10 лет до повальной моды на джаву, серьезный взлет которой начался в районе 1995-го года. В 80-м году альтернативы С в системном программировании в серьезных ОС уже не было, А с какого бока Вы приплели сюда системное программирование? Утверждение моего оппонента, на которое я отвечал, касалось прикладного программирования. История здесь повторилась. Когда появились ЯВУ и стали программировать те самые предметники без глубоких знаний ЭВМ, появилась тенденция, с которой боролись добрых двадцать лет - ассемблерные программисты считались более компетентными просто потому, что они программировали на ассемблере. Сначала, наверное, это так и было, но потом появился слой более чем компетентных прикладников, которые, однако, ценились не так высоко как посредственные ассемблерщики. Не успели закончиться подобные споры, как появился системный Си, добился своего заслуженного места, и начались такие же крики типа "Си - немеряный рулез", пошла точка зрения "крут только потому, что программирует на Си" и на Си стали активно разрабатываться прикладные программы. c127Компилятор был далеко не лучший. Лучший. Microsoft C регулярно выигрывал в различных замерах на эффективность генерируемого кода. В отдельных тестах вперед вырывались другие, но в целом он держал первое место; борландовский компилятор в разговорах позиционировался как "не слишком хуже, но с IDE". c127Например долго не было 32-х разрядного компилятора а у конкурентов был. К моменту появления 32-битных компьютеров борланд уже проиграл, и это мало что могло изменить. c127Оболочка была лучше чем у тех, у кого был лучший компилятор и маркетинг был лучший. Какая оболочка? У Microsoft C не было оболочки, он был command line-овый. Его оболочка называлась Quick C; предполагалось, что программист сначала в этом IDE набивает-отлаживает, а потом компилируется Microsoft C и получает эффективный продукт. c127А у борланда оболочка была лучше, но компилятор хуже и маркетинг хуже. А выигрывает маркетинг и красивая морда. В данном случае выиграл правильный маркетинг. Microsoft сначала привлек к себе профессионалов - своим компилятором. Потом дорисовал студию, и ей в сочетании с примером профессионалов привлек остальных. А борланд остался с посредственным компилятором и устаревшим IDE. C++Builder - сомнительная попытка с сомнительным же успехом. Насчет прогнозов мрачного будущего MS - скажем так: поживем - увидим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:01 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizв версиях бейсика в 98 - 90 годы небыло функций с формальными параметрами. а у фортрана они были изначально. и никогда в фортране не нумеровались строки, как бейсиках Угу, и цикл назывался DO, а FOR, хотя значил в точности то же :) Опираясь на формальные признаки, можно далеко уйти. Впрочем - сколько Вы назовете других известных ЯВУ, в которых, как в фортране и бейсике, можно употреблять необъявленные переменные, причем тип переменной определяется ее именем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:07 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Но с этим согласен не до конца. Кобол очень сложен, гораздо сложнее Фортрана. Согласен, но эта сложность - привнесенная. Изначально пытались сделать нечто типа SQL-я, простой, "близкий к естественному" язык для простых операций. Если бы его рекламировали сегодняшние маркетологи, он бы подавался примерно как Access - "только скажите, что хотите, и это и выполнится". Сложность появилась, когда вполне закономерно выяснилось, что "простого" ни на что серьезное не хватает. Ну и конечно он навсегда останется в истории программирования благодаря замечательному оператору ALTER..PERFORM, если не наврал :) softwarerлинукс - слишком любительская и наколеночная поделка Gluk (Kazan)Согласен, но в последнее время, Linux весьма не плох (и становится все лучше), .... С одним важным комментарием: не плох, если смотреть глазами админа. Глазами человека, который по зову души и кармана профессионально разбирает-собирает этот конструктор, дорабатывает напильником итп. Я - смотрю глазами человека, для которого ОС - что-то типа офисной мебели; сидеть на чем-то надо, но к средствам производства не относится. И в этом случае Linux требует совершенно неадекватного внимания к собственной персоне. Не говоря уже о приятных особенностях программирования под него, например, веселой задачке "написать нетривиальную программу, которая будет одинаково нормально работать как в обычной консоли, так и в иксовой; так чтобы все символы отображались, картинка не сбивалась, горячие клавиши работали...". Gluk (Kazan)Ну и наконец, Linux попортил немало крови Microsoft (читай, создал здоровую конкуренцию). Одно это УЖЕ хорошо. Хорошо. Поскольку подстегивает Microsoft делать неплохие следующие шаги :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:21 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
авторВпрочем - сколько Вы назовете других известных ЯВУ, в которых, как в фортране и бейсике, можно употреблять необъявленные переменные, причем тип переменной определяется ее именем? Perl без use strict :-) А в бейсике "тип переменной определяется ее именем"? А, всякие строковые "A$" - но это было давно, сейчас-то уже нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:23 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей Алексеевич авторНу не только там, макинтоши это сделали гораздо раньше и сейчас лидируют. Мне их интерфейс не понравился, но те кто работает и там и тут говорит что макинтошевский интерфейс гораздо удобнее винды. У тех, кто сидит на маках отношение к майкрософту, если мягко сказать, пренебрежительное, это факт. Что касается интерфейса - вполне возможно, он точно не хуже. Но мак берет не этим, они всё-таки понадежнее писюков (гы, так их и называю) будут. Не из-за одних же красивостей и удобностей оси за железку в два раза больше платят? Странно, а почему тогда мак, свой софт как раз на "писюки" сейчас портирует. Не иначе как чует, что кирдык ему настает, потому как цена маковского железа в разы превышающая "писюковую" не всегда оправдана, далеко не всегда.... это все маркетоиды воду мутят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:27 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуPerl без use strict :-) Perl, кстати, совершенно страшно спроектированный, но довольно забавный язык, если считать забавным принцип "все в кучу". Cкажем, его логические конструкции типа unless я бы вывел из идей LISPа, равно как и его работу с массивами, можно найти и черты Fotran-а, и другие. Это если не иметь в виду очевидных предков :) лыко в строкуА в бейсике "тип переменной определяется ее именем"? А, всякие строковые "A$" - но это было давно, сейчас-то уже нет. Ну так говорится-то о наследовании, то есть о первых версиях. Сегодняшний бейсик похож на какой-нибудь старый Паскаль куда больше, чем на какой-нибудь старый Бейсик :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:39 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer я бы этот все-таки назвал не "именем переменной", а префиксом (для "A$" постфиксом :-)) А то ведь и столь любимый Transact SQL может сюда же попасть со своими @собаками, а так же все shell-ы , tcl, awk и прочая, где есть префиксы у переменных. Личто мне казалось что конструкции типа "A$" были введены для того, чтобы было удобно работать с версиями basic где имя переменной было ограничено одним символом, что было актуально для бытовых персоналок начала 80-х (тех же спектрумах и т.п.) А то букв-то в алфАвите мало! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 12:49 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуsoftwarer я бы этот все-таки назвал не "именем переменной", а префиксом Давайте называть как угодно. Суть одна - по внешнему виду идентификатора определяется его тип. Использование $, #, % - эти типы помню точно, не уверен, что исчерпывающий список - безусловно, более удачный вариант, нежели фортрановский принцип того же, который хорош в основном бессмертным же "GOD IS REAL. UNLESS EXPLICITLY DEFINED AS INTEGER". лыко в строкуА то ведь и столь любимый Transact SQL может сюда же попасть со своими @собаками, а так же все shell-ы , tcl, awk и прочая, где есть префиксы у переменных. Не готов хорошо обсуждать названное. T-SQL - подчеркнутый потомок бейсика; зачем в нем собаки я не знаю, но помню как факт, что аналогичный синтаксис был в ряде "встроенных" бейсиков начала девяностых. Что касается шелловых языков, включая perl - это особый класс; я в принципе соглашусь считать его (если объединить) наравне с популярным ЯВУ. лыко в строкуЛичто мне казалось что конструкции типа "A$" были введены для того, чтобы было удобно работать с версиями basic где имя переменной было ограничено одним символом, что было актуально для бытовых персоналок начала 80-х (тех же спектрумах и т.п.) А то букв-то в алфАвите мало! Насколько я помню, типовым ограничением было "буква либо буква плюс цифра", что давало достаточное для небольшой программы количество идентификаторов. Что касается "введены" - наверное, существовали различные версии, но я помню как минимум две версии бейсика, в которых это было единственным способом определить тип переменной. Оператор DIM определял только массивы, и тип элементов массива определялся опять-таки постфиксом идентификатора массива. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 13:09 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Все это не изменит одного простого факта. Нишу Микрософт на сегодняшний день заполнить НЕКОМУ. Поэтому она может загнивать до опупения, а мы будем продолжать под нее прогибаться. Мы (я) под неё не прогибаемся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 13:24 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
По всем темам топика: альтернатива есть ВСЕГДА. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 13:25 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Я думаю,на самом деле это даже удобно. (по внешнему виду идентификатора определяется его тип) По крайней мере так, как это сделано в Perl, тем более что префиксы гениально мнемонически подобраны. Сразу ясно что к чему. А то тот же Microsoft для подобных целей искусственно изобретал Венгерскую нотацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 13:29 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуЛичто мне казалось что конструкции типа "A$" были введены для того, чтобы было удобно работать с версиями basic где имя переменной было ограничено одним символом, что было актуально для бытовых персоналок начала 80-х (тех же спектрумах и т.п.) А то букв-то в алфАвите мало! В спекртуме по моему макс. длина идентификатора в бейсике была 8 символов. А переменных было два типа - числа (система предпочитала работать с integer, но переходила на real когда была вынуждена) и строки. Чтобы отделить один тип от другого использовался символ $ либо отсутствие оного. В перле символы $, @, и % используются для определения контекста для применения операций. Зачем они в PHP - сие тайна великая есть. Наверное, обезьяничанье над перлом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 13:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
авторВ спекртуме по моему макс. длина идентификатора в бейсике была 8 символов По-моему действительно цифра+буква. В стандартном. Более длинные может были в других, более продвинутых, которых был целый зоопарк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 13:34 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку авторВ спекртуме по моему макс. длина идентификатора в бейсике была 8 символов По-моему действительно цифра+буква. В стандартном. Проверь сам: http://www.twinbee.org/hob/play.php?snap=basic ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 14:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуЯ думаю,на самом деле это даже удобно. (по внешнему виду идентификатора определяется его тип) Это удобно для простых инструментов и простых скриптов. Сходу я бы сказал, отличительные признаки уместных мест: - Отсутствует или мало используется понятие производного типа. Как в Perl, где основные структуры данных - магия компилятора. - Используются короткие идентификаторы. Постфиксы в переменных типа КоличествоТовара# или НаименованиеТовара$ выглядят.. лишними. В фортране, я так полагаю, это появилось для того, чтобы упростить язык; приблизить запись программы к серии формул-выражений. Математик, используя переменную, придумывает ей имя и пихает в формулу - и ему пошли навстречу. лыко в строкуПо крайней мере так, как это сделано в Perl, тем более что префиксы гениально мнемонически подобраны. Сразу ясно что к чему. Это перестает быть ясно и начинает мешать в более сложных случаях. Классическая претензия к префиксной системе: была переменная listOfSomething, в силу чего-либо решили переделать ее на map, и надо то ли переименовывать переменную во всем классе, то ли злобно дезориентировать читающего исходники. лыко в строкуА то тот же Microsoft для подобных целей искусственно изобретал Венгерскую нотацию. Лично я полагаю правильным использовать идентификаторы, не нуждающиеся в подобной расшифровке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 15:09 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
2 Сергей Ильич судя по тому эмулятору = даже 10 символов :-) Мне кажется, это довольно вольная интерпретация изделия К. Синклера Помнится, оригинал такое все же не позволял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 15:14 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку2 Сергей Ильич судя по тому эмулятору = даже 10 символов :-) Мне кажется, это довольно вольная интерпретация изделия К. Синклера Помнится, оригинал такое все же не позволял. Мы с однокашником делали экономический симулятор на синклеровском бейсике по мотивам игры "Диктатор". Программировать мы абсолютно не умели, и заводили переменные по первой нужде и без оной. Тем не менее, нам хватало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 16:17 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Некто Шатохина Н.А. по этому поводу пишет статью о пользе использования различного рода нотаций , сокращений и т.п. Рекомендую почитать. http://www.gotdotnet.ru/LearnDotNet/NETFramework/594.aspx ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 17:35 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
mayton За что не люблю такие тексты - при всех благих пожеланиях сразу вылезают конкретные рога. Например: Все буквы идентификатора заглавные. Используйте нотацию только для идентификаторов, состоящих из двух и менее букв. Например: System.IO System.Web.UI Признаться, не понимаю, почему нужно писать IO и UI, но Bios и Gui. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 17:50 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Согласен .. рогов там немало. Однако на безрыбье - и рак свистит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 17:55 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
mayton Согласен .. рогов там немало. Однако на безрыбье - и рак свистит. Имхо такие бумажки хороши в основном как "рыба" для составления собственной спецификации. Посмотреть, какие вопросы рассмотрены и на какие грабли не стоит наступать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 18:02 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer а почему кстати Вы считаете, что Transact SQL - калька с Basic, на первый взгляд паскалеподобное оно, только все сильно упрощено. Я так понимаю, что за основу PL/SQL в свое время Оракловцы взяли ADA, а при создании Transact SQL MS(Sybase?) "списывали" уже с них? Или как развивалась эта история? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 18:53 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуsoftwarer а почему кстати Вы считаете, что Transact SQL - калька с Basic, на первый взгляд паскалеподобное оно, только все сильно упрощено. Хм. Согласитесь, непросто ответить на вопрос "почему Вы считаете, что А похоже на Б". Особенно в условиях, когда идет взаимопроникновение идей во все стороны. Я могу привести какие-то признаки, но решающим для меня на самом деле будет похожесть на другие продукты, разрабатывавшиеся примерно в то же время и называвшиеся бейсиками. "Паскалевского" в T-SQL - только BEGIN/END, но и тот по-моему давно в бейсиках есть. Но давайте возьмем, например, следующий код на T-SQL (условный, просто раскрывающий конструкции языка): Код: plaintext 1. 2. 3. 4. 5. Как близкий код выглядит на псевдобейсике: Код: plaintext 1. 2. 3. 4. 5. "Псевдо" здесь - поскольку я лет двадцать как не писал на бейсике и не назову версию, которая сможет выполнить такой код; скорее это компиляция из разных источников (например, не уверен, что в современных версиях сохранился оператор LET, который я привел для большей аналогии с SET). Как близкий код выглядит на паскале: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Имхо - больше похоже на бейсик :) лыко в строкуЯ так понимаю, что за основу PL/SQL в свое время Оракловцы взяли ADA, Не берусь утверждать, но не сказал бы. Из ADA взята концепция пакетов, но других черт - не вижу (например, стандартные для оракла неявные преобразования типов в Аде, насколько я помню, строжайше запрещены). лыко в строку а при создании Transact SQL MS(Sybase?) "списывали" уже с них? Или как развивалась эта история? Хм. Признаться, не назову в T-SQL чего-то, что можно было бы назвать списанным с PL/SQL. Разве что списывали очень творчески :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2005, 19:36 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
--null-- c127Возможно, но самое глваное это то что БГ занимается не только мелкософтом, причем мелкософтом он похоже занимается все меньше и меньше. c127, просвети пожалуйста - чем же еще таким занимается БГ, отдавая ентому занятию все больше времени в ущерб Майкрософт? Может, тайно учайствует в разработке того же Linux али же на кухне Sinclair-ы паяет по ночам? :-) Во-первых то что сказал nik_x, во-вторых вообще размещает бабки в далеких от ИТ областях. Чтоб куда-то вложить нужно сначала откуда-то вытащить или куда-то, например в M$, не вложить. Ссылок нет, в новостях как-то проскочило что вкатили ему штраф за какое-то мелкое нарушение правил инвестирования, но думаю что можно найти. softwarer c127Программирование для домохозяек это лозунг нового времени, когда создавался фортран такая чепуха никому в голову не могла прийти. Именно. В те времена был лозунг "программирование для математика/физика/химика..." Та же самая "чепуха", вид сбоку. Ну не совсем, все-таки эти физики-химики в численных методах, которые они программировали, обычно разбирались лучше тех системных программистов, которые для них писали программы. Программист только кодировал. Я немного утрирую, но в принципе так и есть. Чтоб избавиться от такого кодера и от зависимосит от архитектуры придумали фортран. А современные "домохозяйки" кодирующие на васике и джаве обычно не знают ничего вообще. softwarer Зависит от. Возможно, я отстал от жизни, но ничего "специфически удобного" в этом языке я не назову; он просто что успел обрасти отлично отработанными библиотеками. Впрочем, для Wintel-платформы я бы наверное таки выбрал Intel C, благо конверторы фортрана в C давным-давно существуют, а оптимизация все-таки на другом уровне. Его удобство состоит в простоте, кода получается немного меньше, плюс труднее сделать основную сишную ошибку - забыть освободить память. Но самое главное - для фортрана легче написать хороший оптимизатор. Интел фортран кстати тоже существует. softwarer А с какого бока Вы приплели сюда системное программирование? Утверждение моего оппонента, на которое я отвечал, касалось прикладного программирования. Я уже признал что мой пост был не в тему, Вы говорили о С++. Но если говорить о С, то и в прикладном программировании в начале 80-х он был на одном из первых мест. Хотя тогда прикладное программирование это была в основном наука с фортраном. Было еще немного PL/1, совсем немного паскаля и всякая узкоспециализированная экзотика типа кобола. Все ИМХО, статистики нет. softwarer c127Компилятор был далеко не лучший. Лучший. Microsoft C регулярно выигрывал в различных замерах на эффективность генерируемого кода. В отдельных тестах вперед вырывались другие, но в целом он держал первое место; борландовский компилятор в разговорах позиционировался как "не слишком хуже, но с IDE". Это он у борланда выигрывал. softwarer c127Например долго не было 32-х разрядного компилятора а у конкурентов был. К моменту появления 32-битных компьютеров борланд уже проиграл, и это мало что могло изменить. Потому и не мог он быть лучшим, что не было 32-х разрядного компилятора. Он был лучше борланда, но о борланде нет речи. Были еще: ватком, зортек, НДП, которые имели 32 разрядные компиляторы даже для доса и i386, по крайней мере ватком и НДП. В дос-е программа запускалась специальным пускачем, который захватывал процессор, переводил его в 32 разрядный режим и запускал программу. НДП компиляторы были в 89-90 году. Если не ошибаюсь M$ сделал полноценный 32-х разрядный компилятор году аж в 94. О каких тестах можно говорить когда у одного 16 бит, а у другого 32? M$ никогда не строил особо быстрые программы, ватком у него выигрывал. Я уже говорил, что недавно сравнил скорость исполнения M$ кода построенного для пентиума-3 (или 4, не помню) с ваткомомским, построенным для 486 или первого пентиума и ватком проиграл всего на пару процентов, хотя компилятор старше лет на 7. Целочисленная арифметика, процессор был родной для кода пентиум-3 (или 4). Кому нужны были действительно быстрые рассчетные программы использовали НДП. softwarer c127Оболочка была лучше чем у тех, у кого был лучший компилятор и маркетинг был лучший. Какая оболочка? У Microsoft C не было оболочки, он был command line-овый. Его оболочка называлась Quick C; предполагалось, что программист сначала в этом IDE набивает-отлаживает, а потом компилируется Microsoft C и получает эффективный продукт. Вот Quick C и был лучше чем более быстрые конкуренты. А параллельно с ним был MSC-7 с алфавитноцифровым ИДЕ. А у более быстрого НДП оболочки не было вообще, только командная строка. softwarer tchingizв версиях бейсика в 98 - 90 годы небыло функций с формальными параметрами. а у фортрана они были изначально. и никогда в фортране не нумеровались строки, как бейсиках Угу, и цикл назывался DO, а FOR, хотя значил в точности то же :) Все процедурные языки похожи. В таком случае бейсик даже больше похож на С, там даже циклы называются одинаково. softwarerОпираясь на формальные признаки, можно далеко уйти. Впрочем - сколько Вы назовете других известных ЯВУ, в которых, как в фортране и бейсике, можно употреблять необъявленные переменные, причем тип переменной определяется ее именем? В фортране это было сделано чтоб сэкономить на объявлении переменных. Идея очевидная, только на основании этого говорить о похожести языков неоправданно. Отсутсвие формальных параметров по-момеу хороший аргумент в пользу совершенной непохожести этих языков. Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная. softwarer Хм. Согласитесь, непросто ответить на вопрос "почему Вы считаете, что А похоже на Б". ........................ "Псевдо" здесь - поскольку я лет двадцать как не писал на бейсике и не назову версию, которая сможет выполнить такой код; скорее это компиляция из разных источников (например, не уверен, что в современных версиях сохранился оператор LET, который я привел для большей аналогии с SET). Так T-SQL продуктом жизнедеятельности домохозяек и есть, они наверное ничего кроме васика и не знали. Операторы LET-set были введены для того чтоб синтаксически было легче отличать оператор присваивания от оператора сравнения. В фортране с этой целью оператор сравнения записывается как "a.lt.b", а как в С сами знаете. Но в бейсике и с этим тоже путаница, LET можно было не писать, оболочка при запуске это делала за программиста. Но это из-за того что домохозяйки присвоений типа logical i i=a.eq.b используют редко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 00:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer tchingizв версиях бейсика в 98 - 90 годы небыло функций с формальными параметрами. а у фортрана они были изначально. и никогда в фортране не нумеровались строки, как бейсиках Угу, и цикл назывался DO, а FOR, хотя значил в точности то же :) Опираясь на формальные признаки, можно далеко уйти. Впрочем - сколько Вы назовете других известных ЯВУ, в которых, как в фортране и бейсике, можно употреблять необъявленные переменные, причем тип переменной определяется ее именем? дальше чем за теорему, что любая программа может быть написана из последовательного составления конструкции, конструкции ветвления и конструкции цикла - не зайдешь. цикл и ветвление значат в точности тоже у всех (за исключением арифметического фортрана) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 04:05 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Softwarer по поводу яву и обьявления переменных 0 в dBase2 надо было обьявлять переменные? переменные не надо было обьявлять во всех интерпретаторах. 1 в 90 году было 10 000 языков программирования. если поискать языки с таким свойством, то можно найти. (важных атрибутов языка - конечное число гораздо меньшее чем 10000- следовательно, шансы найти сочетания требуемых качеств - высоки) )))) 2 опять же чем это формальное свойство лучше свойства - что у фортрана были локальные переменные и глобальные, а у бейска - только глобальные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 04:11 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizцикл и ветвление значат в точности тоже у всех (за исключением арифметического фортрана) В Фортране нет рекурсии. Вот вам фундаментальное отличие ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 08:06 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
All ... Слышал байку о том, что Америкосы потеряли один из спутников из-за ошибки в программе, которая писана на фортране. Дескать точку с запятой проглядели и все такое. Еще байка есть о том, что первый компилятор Borlanc C в Россию попал путем кражи дистрибутивя прямо из зала ВДНХ. Зато потом продукция Borland пользовалась народной любовью и уважением среди студентов средней руки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 08:48 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
maytonСлышал байку о том, что Америкосы потеряли один из спутников из-за ошибки в программе, которая писана на фортране. Дескать точку с запятой проглядели и все такое. Это ж по моему советский Фобос-1 от этой ошибки умер. И не из-за проглядывания точки с запятой а из-за фортрановского маразма - из-за имени переменной фортран неправельно вывел тип переменной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 09:54 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Нет, Американская ракета-носитель со спутником запускавшимся на Венеру, если не ошибаюсь. Вместо одной запятой, стояла точка. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 10:06 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Вы про это: http://www.osp.ru/os/1998/06/21.htm (в том числе) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 10:18 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127 softwarer c127Программирование для домохозяек это лозунг нового времени, когда создавался фортран такая чепуха никому в голову не могла прийти. Именно. В те времена был лозунг "программирование для математика/физика/химика..." Та же самая "чепуха", вид сбоку. Ну не совсем, все-таки эти физики-химики в численных методах, которые они программировали, обычно разбирались лучше тех системных программистов, Именно. Точно так же как домохозяйка разбирается в содержимом своего холодильника лучше, нежели программист, который пишет программу оптимального наполнения холодильника. Суть одна и та же - дать предметнику возможность работать "без посредников". Вопрос только в масштабах - в те времена стоимость машинного времени могла тратиться на математиков, сейчас - может и на домохозяек. c127Его удобство состоит в простоте, кода получается немного меньше, Хм. Если говорить о Fortran IV, то он на мой вкус был перегружен архаичными по сегодняшним меркам конструкциями - те же операторы FORMAT чего стоят. Ну и часто вспоминаемые мной интересные особенности, например, кажется ENTRY SET - альтернативная точка входа в функцию. Если же говорить о Fortran 77/90, то серьезно я их не изучал, но на первый взгляд они показались мне "испорченным паскалем" - примерно то же по возможностям, но более громоздкий синтаксис. c127плюс труднее сделать основную сишную ошибку - забыть освободить память. Этот аргумент я не приму. Никто не заставляет пользоваться динамической памятью, даже если она есть в языке. Конверторы Фортрана на Си существуют именно потому, что программы очень легко перекладываются "один в один". Разница в том, что в фортране приходилось очень нехило извращаться, эмулируя динамическое распределение там, где оно было нужно. Впрочем, динамическая память - в любом случае атрибут более поздних языков, уже семидесятых годов. Если не ошибаюсь, в Fortran 77 она уже есть. c127Но самое главное - для фортрана легче написать хороший оптимизатор. Интел фортран кстати тоже существует. Легче - просто потому, что язык относительно небогат. Хотя именно поэтому не совсем уверен в хорошей оптимизации конструкций, эмулирующих отсутствующие возможности. Грубо говоря, оптимизировать Сишный цикл for проще, нежели фортрановскую if-goto, его эмулирующую. Оптимизировать Сишный switch проще, нежели фортрановский вычисляемый goto (поскольку последний куда более произволен, например может использоваться для организации нестабильного цикла). Безусловно, существует все. Интел Си я просто упомянул, чтобы закрыть вопрос оптимизации - мягко говоря, нелегко найти того, кто лучше оптимизит сложные вычисления, а следовательно нет причин отказываться от более мощного и - сегодня - более привычного языка. c127 softwarer c127Компилятор был далеко не лучший. Лучший. Microsoft C регулярно выигрывал в различных замерах на эффективность генерируемого кода. В отдельных тестах вперед вырывались другие, но в целом он держал первое место; борландовский компилятор в разговорах позиционировался как "не слишком хуже, но с IDE". Это он у борланда выигрывал. Скажем так, остальные выигрывали у него в каких-то областях, но по средневзвешенному, с моей точки зрения, он их обходил. Впрочем, в рамках истории "MS vs BRLND" хватит и Вашего утверждения - у MS был лучше компилятор C, и он умело реализовал это преимущество. c127Потому и не мог он быть лучшим, что не было 32-х разрядного компилятора. Он был лучше борланда, но о борланде нет речи. Были еще: ватком, зортек, НДП, которые имели 32 разрядные компиляторы даже для доса и i386, по крайней мере ватком и НДП. В дос-е программа запускалась специальным пускачем, который захватывал процессор, переводил его в 32 Я пользовался ваткомовским компилятором с dos4g (я имею в виду полный, а не обрезанный gos4gw). И хотя понятно, почему он использовался для игр - таки 8Mb прямой оперативки есть 8Mb - но генерируемый им код, честно говоря, не очень впечатлял. НДП - не знаю, не встречал, не могу судить. c127Все процедурные языки похожи. В таком случае бейсик даже больше похож на С, там даже циклы называются одинаково. Если судить по внешним, формальным признакам - безусловно. Если Вы не заметили, именно над этим я и иронизирую. c127В фортране это было сделано чтоб сэкономить на объявлении переменных. Идея очевидная, только на основании этого говорить о похожести языков неоправданно. Веселый Вы человек. Мой оппонент выдвигает.. плохой, назовем так, аргумент. Я показываю другой аргумент, построенный по той же логике и очевидно плохой - показывая этим, что подобная логика хрома на обе ноги. Теперь Вы считаете, что именно на этом основании я сужу о похожести. c127Отсутсвие формальных параметров по-момеу хороший аргумент в пользу совершенной непохожести этих языков. Учитывая, что в первых бейсиках по сути не было подпрограмм, в них действительно трудно найти формальные параметры :) c127Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная. Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было. А учитывая отсутствие в бейсике подпрограмм и работу в едином пространстве памяти - глупо ожидать наличия механизмов, предназначенных именно для межподпрограммного взаимодействия. Я не очень понимаю Вашей точки зрения "раз наследник - значит, должен быть шире". Но если угодно продолжить, то: - В бейсике, как и в фортране, присутствует уникальный на тот момент оператор DATA. Если не ошибаюсь, позже его повторили опять же в Perl, и других мест я сходу не назову. - В бейсике, как и в фортране, присутствовал только арифметический цикл с произвольным шагом, включая вещественный (цикл WHILE появился в бейсиках намного позже). - В бейсике, как и в фортране, в отличие от любых других языков выше ассемблера, существовала возможность передать управление в середину подпрограммы. - В бейсике, как и в фортране, отсутствовало понятие операторного блока, что вынуждало использовать GOTO для его эмуляции. - В бейсике, как и в фортране, существовал вычисляемый GOTO (насчет его наличия в других языках того же периода - не уверен, не помню). - Cхема работы бейсика с файлами была почти стопроцентно слизана с фортрановской. - В бейсике, как и в фортране, существовал оператор STOP - В бейсике, как и в фортране, длина метки была ограничена пятью символами :)) (в стандартных реализациях для мини-ЭВМ). Названное, за исключением последнего пункта - с поправкой на мои неполные знания - отличает именно эту пару от всех или почти всех распространенных языков той поры. c127 Так T-SQL продуктом жизнедеятельности домохозяек и есть, они наверное ничего кроме васика и не знали. ...... При чем тут это? Мой оппонент спросил меня, почему я считаю эти языки похожими. Я постарался показать, почему. Я собственно уверен, что их специально делали похожими - в ту пору была мода везде делать встроенный бейсик. Это не обвинение и ничто похожее - это просто факт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 11:19 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizв dBase2 надо было обьявлять переменные? Представления не имею. Я читал о нем где-то в начале восьмидесятых и никогда не пользовался. tchingizпеременные не надо было обьявлять во всех интерпретаторах. И с каких пор фортран стал интерпретатором? Впрочем, и в этом утверждении Вы, мягко говоря, хватили. Например, мне сразу вспоминается вполне себе интерпретатор R-LISP-а. tchingizв 90 году было 10 000 языков программирования. если поискать языки с таким свойством, то можно найти. Поэтому я старался говорить о распространенных ЯВУ. Нераспространенный, если нужно, я сам за пару дней напишу :) tchingizопять же чем это формальное свойство лучше свойства - что у фортрана были локальные переменные и глобальные, а у бейска - только глобальные. Ничем. Я как раз показываю, что сугубо формальные свойства имеют очень мало отношения к сути. Хотя это, пожалуй, таки больше относится к делу, нежели названные Вами номера строк (которые были вызваны переходом от перфокарт к строковому редактору, и вряд ли чем-то другим. И исчезли вместе с исчезновением строкововых редакторов). Кстати, а у фортрана разве были глобальные переменные? У него, сколь помнится, были common-области. Бейсик-программа же в целом похожа на одну-единственную подпрограмму (SUBROUTINE) фортран-программы; операторы GOSUB/RETURN бейсика больше похожи не на подпрограмму в ее нормальном смысле, а на фортрановский "назначаемый GOTO". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 11:27 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Сергей ИльичЭто ж по моему советский Фобос-1 от этой ошибки умер. Фобос помер от маразма - программист, делая тривиальную изменение (кажется, что-то в сбрасываемой на Землю телеметрии) не прогнал новый вариант на тестовом стенде. И поуправлял не той аппаратурой - развернул солнечные батареи ребром к Солнцу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 11:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer- В бейсике, как и в фортране, в отличие от любых других языков выше ассемблера, существовала возможность передать управление в середину подпрограммы. буду педантом, но разве longjmp в C не делает этого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 11:49 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкубуду педантом, но разве longjmp в C не делает этого? Хм. longjmp возвращает управление в указанную точку, а не передает . Пара setjmp/longjmp в чем-то аналогична бейсиковским gosub/return, но при этом longjmp играет роль именно return-а. И при этом отсутствует возможность вызвать подпрограмму (завершающуюся этим return-ом) с произвольного места, как оно возможно в случае gosub. Пожалуй, рискну утверждать, что бейсиковский код вида Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. практически невозможно адекватно эмулировать с помощью longjmp. "Адекватно" здесь следует понимать так - такой код можно будет упростить, отказавшись от longjmp при сохранении результата. Если искать среди бейсиковских конструкций аналог longjmp, то это RESUME, хотя сходство все равно очень дальнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 12:37 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer Именно. Точно так же как домохозяйка разбирается в содержимом своего холодильника лучше, нежели программист, который пишет программу оптимального наполнения холодильника. Разница в том, что программами для упаковки холодильника никто не пользуется, а как видно из приведенного тут примера, на фортрановских программах летали в космос, правда не всегда успешно. Фортран никогда не претендовал на универсальность и никто из нормальных людей в качестве универсального его использовать не предлагал. Сидел в своей нише и не высовывался. А вот бейсик пытаются использовать как универсльный язык, компилятор написали, даже пытались на нем что-то считать и рассказывали что он не уступает по скорости С, поэтому все пишем на бейсике. softwarer Суть одна и та же - дать предметнику возможность работать "без посредников". Вопрос только в масштабах - в те времена стоимость машинного времени могла тратиться на математиков, сейчас - может и на домохозяек. В мире вообще все похоже если отойти на достаточное расстояние. Проблема классификации. softwarer Хм. Если говорить о Fortran IV, то он на мой вкус был перегружен архаичными по сегодняшним меркам конструкциями - те же операторы FORMAT чего стоят. Как раз фортран хорош тем, что в нем мало лишнего. Формат часто бывает очень удобен. Правда его легко сэмулировать. А чем он еще перегружен? softwarer Ну и часто вспоминаемые мной интересные особенности, например, кажется ENTRY SET - альтернативная точка входа в функцию. Если же говорить о Fortran 77/90, то серьезно я их не изучал, но на первый взгляд они показались мне "испорченным паскалем" - примерно то же по возможностям, но более громоздкий синтаксис. Это называлось ENTRY POINT, который в подпрограмме выглядел как "ENTRY имя(параметры)". Возможности у всех полных языков одиинаковые, поэтому их обсуждать нет смысла, есть смысл обсуждать только удобство для программиста пишушего программу и пишушего компилятор. softwarer c127плюс труднее сделать основную сишную ошибку - забыть освободить память. Этот аргумент я не приму. Никто не заставляет пользоваться динамической памятью, даже если она есть в языке. Конверторы Фортрана на Си существуют именно потому, что программы очень легко перекладываются "один в один". Разница в том, что в фортране приходилось очень нехило извращаться, эмулируя динамическое распределение там, где оно было нужно. Ну да. Переведите один в один subroutine f(n) real y(n) return end Это динамическое распределение памяти, большее в типичной счетной задаче редко когда нужно. Правда по-моему появилось в фортране 77. Тип complex вспоминать не будем. softwarer c127Но самое главное - для фортрана легче написать хороший оптимизатор. Легче - просто потому, что язык относительно небогат. Совершенно верно, а больше и не нужно. Сила фортрана в том, что он имеет достаточно необходимых средств и не имеет много лишних. softwarer Хотя именно поэтому не совсем уверен в хорошей оптимизации конструкций, эмулирующих отсутствующие возможности. Грубо говоря, оптимизировать Сишный цикл for проще, нежели фортрановскую if-goto, его эмулирующую. Аналогом цикла for есть цикл do, а его оптимизировать проще. Всякие хитрые циклы с хитрыми условиями выхода и приращениями пяти переменных в типичной задаче для фортрана почти никогда не нужны, зато они не запутывают оптимизатор. Все равно всеми возможностями цикла for никто не пользуется. softwarer Оптимизировать сишный switch проще, нежели фортрановский вычисляемый goto (поскольку последний куда более произволен, например может использоваться для организации нестабильного цикла). switch удобный оператор, в фортране появился. Не знаю легче ли его. Но опять же в типичной счетной задаче switch возникает довольно редко и еще реже в циклах. А вне цикла можно вообще ничего не оптимизировать. softwarer Безусловно, существует все. Интел Си я просто упомянул, чтобы закрыть вопрос оптимизации - мягко говоря, нелегко найти того, кто лучше оптимизит сложные вычисления, а следовательно нет причин отказываться от более мощного и - сегодня - более привычного языка. Так я ж не призываю Вас отказываться. У каждого языка своя ниша, задачи с плавающей точкой на фортране считать легче, всякие списки, графы и системные задачи легче писать на С. softwarer Я пользовался ваткомовским компилятором с dos4g (я имею в виду полный, а не обрезанный gos4gw). И хотя понятно, почему он использовался для игр - таки 8Mb прямой оперативки есть 8Mb - но генерируемый им код, честно говоря, не очень впечатлял. НДП - не знаю, не встречал, не могу судить. Я сужу по тем задачам которые решал сам. Хотя на самом деле скорости M$ всегда хватало, после появления 32-х разрядного компилятора разумеется, либо же никакой код не спарвлялся. M$ потому и победил что та разница в скорости, которую давали конкуренты некритична в большинстве случаев и мало кого беспокоит, как оказалось. softwarer Веселый Вы человек. Мой оппонент выдвигает.. плохой, назовем так, аргумент. Формальные параметры ОЧЕНЬ ХОРОШИЙ АРГУМЕНТ. ИМХО. Ваш аргумент с циклами по сравнению с ним совсем не в тему. Опять же ИМХО. softwarer Учитывая, что в первых бейсиках по сути не было подпрограмм, в них действительно трудно найти формальные параметры :) Подпрограммы были, можно было написать что-то вроде 200 .... 300 return go sub 200 .... go sub 200 То что между 200 и 300 и есть полноценная подпрограмма, которая вернется в точку вызова. Это основное главное свойство подпрограмм. Следующее свойство - формальные параметры, но оно не необходимое, хотя важное. Понимание смысла формальнх параметров это одно из необходимых условий перехода от домохозяйки к программисту. Поэтому я считаю что аргумент с формальными параметрами очень удачен. softwarer c127Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная. Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было. Альтернатива всегда есть, поэтому речь идет именно об удобстве, экономит много кода. softwarer Я не очень понимаю Вашей точки зрения "раз наследник - значит, должен быть шире". При чем тут шире-не шире, я такого не говорил. Я не думаю что бейсик какой-то особый наследник фортрана. Они появились примерно в одно время, я правда не видел тот бейсик. Даже если бейсик и создавался с оглядкой на фортран (что возможно), то в результате сходство между ними к моменту реанимации бейсика в начале 80-х оказалось не больше чем между паскалем и С. Их некоторое сходство скорее всего объясняется тем что они появились в середине 60-х (фортран чуть раньше, а бейсик скорее на бумаге), тогда экономия на компиляторе и на размере необходимой для компилирования памяти была необходимостью. Кроме того такого изобилия языков как сейчас не было и по-видимому создатель бейсика знал о фортране и ничего другого не мог себе представить. Изменил как мог. Хотя цели и предполагаемые пользователи этих языков совершенно разные. softwarer Но если угодно продолжить, то: - В бейсике, как и в фортране, присутствует уникальный на тот момент оператор DATA. Если не ошибаюсь, позже его повторили опять же в Perl, и других мест я сходу не назову. - В бейсике, как и в фортране, присутствовал только арифметический цикл с произвольным шагом, включая вещественный (цикл WHILE появился в бейсиках намного позже). WHILE не сильно нужен, а компилятор упрощается. Экономили, в этом причина. softwarer - В бейсике, как и в фортране, в отличие от любых других языков выше ассемблера, существовала возможность передать управление в середину подпрограммы. Возможно, хотя как это выглядит в бейсике я не помню. Говорят в С это тоже как-то возможно, но как не знаю, а думать лень. softwarer - В бейсике, как и в фортране, отсутствовало понятие операторного блока, что вынуждало использовать GOTO для его эмуляции. "вынуждало" это сильно сказано, можно обойтись без него. В 77 вообще легко можно обойтись без GOTO. Но в принципе согласен. Объясняется тем же. В алголе который появился примерно в то же время тоже интенсивно использовался GOTO, хотя там были блоки. GOTO есть и в С с паскалем. Операторные блоки сильно усложняют компилятор. Для алгола долго не могли построить компилятор, в частности из-за операторных блоков. softwarer - В бейсике, как и в фортране, существовал вычисляемый GOTO (насчет его наличия в других языках того же периода - не уверен, не помню). Может быть. В бейсике я его не помню. softwarer - Cхема работы бейсика с файлами была почти стопроцентно слизана с фортрановской. Этого я не понимаю. Схемы работы с файлами по-моему вообще у всех одинаковые. softwarer - В бейсике, как и в фортране, существовал оператор STOP Смысл этого оператора всегда был для меня загадкой. Его можно исключить из языка и никто не заметит, к тому же, если не ошибаюсь, у стопа в этих языках разный смысл. softwarer - В бейсике, как и в фортране, длина метки была ограничена пятью символами :)) (в стандартных реализациях для мини-ЭВМ). Шутку понял. В бейсике это не метка, это номер (адрес, идентификатор) строки в программе. Номера идут по-порядку. А вот в фортране это действительно метка. В фортране метки в разных подпрограммах могли дублироваться, а в бейсике номера строк - нет. softwarer Названное, за исключением последнего пункта - с поправкой на мои неполные знания - отличает именно эту пару от всех или почти всех распространенных языков той поры. Если Вы посмотрите на языки действительно той поры (60-е годы), то наверняка увидите что они очень похожи. Хотя я не смотрел, может и ошибаюсь. Лисп не считается, он функциональный. Gluk (Kazan) В Фортране нет рекурсии. Вот вам фундаментальное отличие ;) Это только в самых ранних версиях, потом все испортили, ввели рекурсию. А как хорошо начиналось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2005, 22:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) tchingizцикл и ветвление значат в точности тоже у всех (за исключением арифметического фортрана) В Фортране нет рекурсии. Вот вам фундаментальное отличие ;) это не фундаментальное отличие. рекурсия однозначно соответствует итерации и наоборот. ))))))))))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 08:40 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer tchingizпеременные не надо было обьявлять во всех интерпретаторах. И с каких пор фортран стал интерпретатором? Впрочем, и в этом утверждении Вы, мягко говоря, хватили. Например, мне сразу вспоминается вполне себе интерпретатор R-LISP-а. .... Поэтому я старался говорить о распространенных ЯВУ. Нераспространенный, если нужно, я сам за пару дней напишу :) .... Хотя это, пожалуй, таки больше относится к делу, нежели названные Вами номера строк (которые были вызваны переходом от перфокарт к строковому редактору, и вряд ли чем-то другим. И исчезли вместе с исчезновением строкововых редакторов). Кстати, а у фортрана разве были глобальные переменные? У него, сколь помнится, были common-области. Бейсик-программа же в целом похожа на одну-единственную подпрограмму (SUBROUTINE) фортран-программы; операторы GOSUB/RETURN бейсика больше похожи не на подпрограмму в ее нормальном смысле, а на фортрановский "назначаемый GOTO". фортран - компилятор, в любом интерпретаторе не надо обьявлять переменные. не думаю, что любой интерпретатор, на этом основании, является наследником фортрана. кстати, perl удовлетворяет Вашей просьбе назвать язык, где бы имя переменной задавало тип. Там както по имени скаляры от массивов отличаются. Глобальные переменные жили в коммон областях. Они просто не назывались глобальными, но суть таже, отовсюду к ним был доступ. Думаю, что бейсик был позже фортрана, а Вы пишите, что программа бейсика, в целом похожа на одну фортран программу. Не принято както отказываться от хороших качеств. Наследник бы наследовал хорошие качества. сомнительно Ваше утверждение softwarer>Фортран - предок бейсика Скорее разработчики бейсика делали, что могли. вот язык ratfor (rational fortran) разработанный как препроцессор для фортрана под никсами уже обладал всеми атрибутами структурного программирования (циклы while, until, отсутствие меток и операторные скобки), и все равно мог бы считаться наследником фортрана. Формальная грамматика ратфора представляла из себя 10-12 строчек. Для своей версии ратфора, я еще добавил операции ++, --, +=, -= и тд. И думаю это не изменило свойства фортрана быть предком ратфора от меня. )))))))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 09:01 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizрекурсия однозначно соответствует итерации и наоборот. ))))))))))) Ага, некоторые алгоритмы переводить в итеративную форму одно удовольствие :o) Ладно, сможете здесь набросать в итеративной форме альфа-бета алгоритм ? Нууу или Ханойские башенки хотя-бы ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 09:22 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingiz это не фундаментальное отличие. рекурсия однозначно соответствует итерации и наоборот. ))))))))))) Добавлю. Рекурсия эмулируется с использованием LIFO-очереди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 10:26 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127В мире вообще все похоже если отойти на достаточное расстояние. Проблема классификации. Согласен. Предлагаю закрыть эту часть беседы констатацией того, что мы классифицируем некоторый факт по-разному. c127Формат часто бывает очень удобен. Правда его легко сэмулировать. А чем он еще перегружен? Возможно, тут вопрос подхода. С моей точки зрения то, что может быть вынесено из языка, должно быть вынесено из языка - это собственно и есть "разгрузка". Сравнивая два фрагмента кода: Код: plaintext 1. 2. и Код: plaintext 1. я бы назвал первый значительно менее удачным. Его несколько сомнительное достоинство - возможность использовать один и тот же формат в нескольких операторах. То есть - не сделать подпрограммы там, где она напрашивается :) Другие неудачи - вычисляемый GOTO и арифметический IF как довольно неуклюжие замены case/switch. COMMON области как неуклюжие замены глобальных переменных (я бы сказал даже, не столько глобальных переменных, сколько конструкции record/struct. Структуру нетрудно передать параметром подпрограммы, в отличие от пятидесяти ее полей поодиночке - поэтому ее и передавали через common область). Напрасное, с моей точки зрения, выделение трех (если не изменяет память) принципиально разных типов подпрограмм. Назначаемый GOTO - специфическая конструкция, мягко говоря не для "языка для непрограммистов". Замечательный оператор IMPLICIT :) Наверное, если откопаю книгу, еще что-нибудь вспомню. eНу да. Переведите один в один subroutine f(n) real y(n) return end[/quote] Признаться, не понимаю этого фрагмента. Судя по Вашим словам, этот массив должен каким-то образом вернуться из подпрограммы, но каким - видимо, я либо тупой, либо слишком хорошо забыл Fortran. Впрочем, согласитесь, "создание массива размерности N" переводится на Си совершенно элементарно. Здесь оказывается очень удобной особенность "массивы есть указатели" - что в случае Код: plaintext что в случае Код: plaintext работа с массивом a идет абсолютно одинаково. Собственно, если бы я писал конвертор, я бы, наверное, просто всегда пользовался вторым вариантом. Совершенно верно, а больше и не нужно. Сила фортрана в том, что он имеет достаточно необходимых средств и не имеет много лишних. Я не считаю, что отсутствие развитых циклов, например - лишнее. Арифметический цикл - хорошо, но стандартнейшая задача "арифметический цикл с условием досрочного выхода" - решается в PL/I, решается в паскале/си, но не в фортране. Вернее, если не ошибаюсь, в фортране она решается на уровне IF..GOTO - можно, в принципе но не лучший вариант. Если говорить о вычислениях - давайте вспомним о такой стандартнейшем математическом приеме, как вычисление с переменным шагом (не помню, как это называется "по научному", но абсолютно стандартная вещь для задач типа "интегрирование с заданной точностью"). В Си это - тот же цикл for. В Паскале это - например, цикл while. В Фортране это - IF/GOTO. Код: plaintext Код: plaintext потребуется очень нетривиально дорабатывать, чтобы он смог оптимизировать аналогичную конструкцию Фортрана. К чему я это - к тому, что у Фортрана как языка нет никаких особых преимуществ по оптимизации. В самом лучшем случае авторы конкретного компилятора просто выполнили свою работу лучше авторов соседнего компилятора Си - но, признаться, сомневаюсь, что так случилось. Все равно всеми возможностями цикла for никто не пользуется. "Отучаемся говорить за всех" (c) Знаете, пока я не поработал с исключениями, вполне нормально делал аналогичные механизмы имеющимися средствами. Пока я не поработал с LISPом - не ощущал отсутствия некоторых его конструкций в других языках. Пока не ушел с Си на "не Си" - считал операцию ? удобной, но не более того. И так далее. К хорошему привыкаешь, и учишься его хорошо использовать. Так я ж не призываю Вас отказываться. У каждого языка своя ниша, задачи с плавающей точкой на фортране считать легче, всякие списки, графы и системные задачи легче писать на С. Хм. Так если помните, эта часть беседы началась с фразы одного из присутствующих о полной прикладной победе Си. Я ответил на это, что лет двадцать назад это же могли бы сказать о Фортране - и были бы столь же корректны. Как модно нынче говорить, there is no silver bullet. Формальные параметры ОЧЕНЬ ХОРОШИЙ АРГУМЕНТ. ИМХО. Ваш аргумент с циклами по сравнению с ним совсем не в тему. Опять же ИМХО. Конечно, можно сойтись на имхах. Я бы сказал так: цикл - более "коренная", необходимая структура языка, нежели подпрограмма, следовательно и сходства-различия в них более важны с точки зрения похожести. Ну а фантазировать "какими были бы подпрограммы в первых бейсиках, если они там были..." Но не было. По сути, от них отказались так же, как и от некоторых других фортрановских конструкций. softwarer Учитывая, что в первых бейсиках по сути не было подпрограмм, в них действительно трудно найти формальные параметры :) Подпрограммы были, можно было написать что-то вроде 200 .... 300 return go sub 200 .... go sub 200 То что между 200 и 300 и есть полноценная подпрограмма, которая вернется в точку вызова. Полноценная подпрограмма? Думаю, мы не сойдемся в определениях. Близкий аналог этой конструкции я использовал в bat-файлах (помните такой язык для DOS?) примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Бейсиковские GOSUB/RETURN - это именно что аналог setjmp/longjmp в Си или назначаемого GOTO в Фортране, но подпрограммами это - только называется. Это основное главное свойство подпрограмм. Следующее свойство - формальные параметры, но оно не необходимое, хотя важное. Понимание Не согласен. Основное свойство подпрограммы - замкнутость; это самостоятельная (в определенных пределах, конечно) программная единица. Из чего неизбежно следует понятие "контекста выполнения подпрограммы", "области видимости" (раньше в англоязычной литературе это называлось display). "Подпрограмма, чей контекст заведомо совпадает с родительским" - формальный уродец, такой же, как показанный выше пример с GOTO. смысла формальнх параметров это одно из необходимых условий перехода от домохозяйки к программисту. Хм. Я не уверен, что понимаю Вас. В первую очередь: имеете ли Вы в виду именно параметры как таковые (то есть логическое противопоставление формальный-фактический), то ли Вы имеете в виду под формальными параметрами фортрановскую "передачу по ссылке". Я бы сказал, параметры есть естественный атрибут подпрограмм; невозможно понять смысл подпрограмм, не поняв смысла их параметров. Проведение именно здесь какой-то границы между "гуру" и "домохозяйками" - имхо, совершенно произвольный жест. Хотя все - понятие относительное. Мой научный руководитель говорил, что не понимает указателей, что не мешало мне научиться у него некоторым интересным способам программистского мышления. Поэтому я считаю что аргумент с формальными параметрами очень удачен. С какой точки зрения? Как различие между языками - безусловно, важное различие. Но это ровно никак не относится к обоснованию или опровержению моего утверждения (о том, что бейсик разрабатывался как идеологический наследник фортрана). Позволю себе использовать Ваш аргумент: если из Фортрана "для простоты" убрали циклы, кроме тривиального, то в Бейсике развили эту идею и "для простоты" убрали "параметры подпрограмм" (с Вашей точки зрения) или "подпрограммы" (с моей). Подчеркну на всякий случай: это не есть утверждение, которое я считаю верным. Это опровержение Вашей схемы рассуждения методом "от противного". c127 softwarer [quot c127]Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная. Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было. Альтернатива всегда есть, поэтому речь идет именно об удобстве, экономит много кода. Давайте так - "не было разумной альтернативы". Разумной альтернативой явилась бы структура/запись, которую можно было бы заполнить и передать как один параметр. Ну а то, с какой осторожностью надо использовать common области, полагаю, не мне Вам рассказывать. c127При чем тут шире-не шире, я такого не говорил. Я не думаю что бейсик какой-то особый наследник фортрана. Хм. Я думаю, что Бейсик - наследник Фортрана. Чингиз, а следом и Вы, решили поспорить с этим, выдвигая основным аргументом отсутствие одной из конструкций, существующих в Фортране - то есть то, что Бейсик не реализует одной из важных особенностей "предка". Поэтому я и сказал, что наследник вовсе не обязан быть "шире" предка; тезис "уже - значит, не наследник" не представляется мне бесспорно верным. Они появились примерно в одно время, я правда не видел тот бейсик. Между ними - семь лет разницы. По утверждению создателя (можно найти точную цитату), Бейсик создавался как учебный язык для студентов, как ступенька для перехода на более мощные Фортран и Алгол (что вполне обосновывает его относительную убогость). Ну и если сравнить из Фортрана и Алгола, на кого больше похож Бейсик - ответ, имхо, совершенно однозначен. В противопоставление созданному позже учебному Паскалю, похожему именно на Алгол. Даже если бейсик и создавался с оглядкой на фортран (что возможно), то в результате сходство между ними к моменту реанимации бейсика в начале 80-х оказалось не больше чем между паскалем и С. Давайте для экономии времени я сформулирую утверждение: я уверен, что если мы с Вами согласуем список формальных признаков (наличие тех или иных конструкций и концепций), то из "прочих основных языков того времени" фортран окажется самым близким или по крайней мере одним из самых близких. Кроме того такого изобилия языков как сейчас не было и по-видимому создатель бейсика знал о фортране и ничего другого не мог себе представить. Не соглашусь. К тому моменту существовало порядка десятка "основных" языков, тех, названия которых сейчас можно вспомнить не напрягаясь: FORTRAN, ALGOL, APL, SIMULA, PL/I, COBOL, LISP. И на самом деле тогда был некий взрыв языкотворчества; раскрывалась новая область, из которой до нас дошли наиболее удачные либо наиболее удачливые представители. Изменил как мог. Хотя цели и предполагаемые пользователи этих языков совершенно разные. Цель - учить тех, кто потом будет программировать на Фортране. "И программировать для тех, кому Фортран сложен" - это уже мое дополнение; это не было изначальной целью, но именно для этого Бейсик как Вы выразились, "реанимировали". WHILE не сильно нужен, а компилятор упрощается. Экономили, в этом причина. WHILE сильно нужен, по крайней мере с точки зрения человека, у которого была возможность выбора. Что касается экономии - я приму этот аргумент для Fortran I-II, но не очень поверю в него для Fortran IV. Если помните, к тому моменту IBM разработала совершенно монструозный по отзывам современников, четырехпроходный, кажется, компилятор, выполнявшийся отдельными стадиями - говоря современным языком, для полной компиляции требовалось запустить несколько exe-шников по очереди. Так что в аргумент "экономили" верится, признаться, с трудом. softwarer - В бейсике, как и в фортране, в отличие от любых других языков выше ассемблера, существовала возможность передать управление в середину подпрограммы. Возможно, хотя как это выглядит в бейсике я не помню. Да так и выглядит. GOSUB. Только не на ту строчку, которую мы считаем "началом подпрограммы", а на ту, которую мы считаем "серединой". Поскольку подпрограммы нет (по крайней мере как присутствующей в языке синтаксической конструкции) все просто. Запросто возможен код типа следующего: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Ну и - этот код, наверное, как-то отработает, но назвать его "программой с подпрограммой" я лично не возьмусь. Говорят в С это тоже как-то возможно, но как не знаю, а думать лень. Полагаю, если говорить о нормальных конструкциях языка, о подразумеваемом их использовании, говорят ошибочно. Разумеется, это можно сделать с помощью адресной арифметики - сотворить указатель на (&func() + 0x20), например, и перейти по нему. "вынуждало" это сильно сказано, можно обойтись без него. Технически - можно. Например, оформлять на месте операторного блока вызов подпрограммы. Но в данном случае "все и всегда" делали именно GOTO - собственно, во многих версиях Бейсика даже не было возможности написать в IF что-то отличное от GOTO. Операторные блоки сильно усложняют компилятор. Для алгола долго не могли построить компилятор, в частности из-за операторных блоков. Хм. Такое впечатление, что Вы начинаете как-то "защищать" решения Фортрана. Я на них не нападаю. Нет - и нет, это факт, с которым придется жить если хочешь программировать на Фортране. Просто один из формальных критериев схожести, раз уж они потребовались. softwarer - В бейсике, как и в фортране, существовал вычисляемый GOTO (насчет его наличия в других языках того же периода - не уверен, не помню). Может быть. В бейсике я его не помню. Скажем так, в том бейсике, которым пользовался я, он был. Если принципиально, можно залезть в стандарт, но не думаю, что это важно. softwarer - Cхема работы бейсика с файлами была почти стопроцентно слизана с фортрановской. Этого я не понимаю. Схемы работы с файлами по-моему вообще у всех одинаковые. Да не сказал бы. Признаться, не помню как в ALGOL и PL/I - может, это было обычно в те времена - но по сравнению с более поздними временами эта схема раритетна. В классическом паскале она достаточно похожа, но все-таки введено важное понятие "файловой переменной"; в результате, например, файл можно передать параметром в подпрограмму. В Си и в более поздних версиях Паскаля сделано правильнее: работа с файлами убрана на уровень библиотек, функций/классов с уровня операторов языка. STOP Смысл этого оператора всегда был для меня загадкой. Его можно исключить из языка и никто не заметит, к тому же, если не ошибаюсь, у стопа в этих языках разный смысл. Признаться, не помню в деталях его смысл в том и в другом случае. Но согласитесь, если это "бессмысленное украшение" - это как раз свидетельствует о прямом заимствовании, копировании, там, где наличие похожих осмысленных конструкций можно отнести на счет объективной необходимости и "есть во всех языках". Шутку понял. В бейсике это не метка, это номер (адрес, идентификатор) строки в программе. Номера идут по-порядку. А вот в фортране это Безусловно, это шутка. Но в данном случае "для простоты" одним механизмом достигли двух целей - делали метки и одновременно делали "опорные точки" для строкового редактора. С точки зрения логики языка это именно метки; в том, что программа строится по возрастанию номеров, а не по порядку ввода, с точки зрения языка нет ничего принципиального. действительно метка. В фортране метки в разных подпрограммах могли дублироваться, а в бейсике номера строк - нет. Дык в бейсике и не было "разных подпрограмм" в фортрановском смысле - там был единый контекст выполнения, общие переменные, ну и общая область видимости меток. Если делать конвертор бейсика в фортран - надо будет делать всю бейсик-программу единственной SUBROUTINE, а GOSUB/RETURN реализовывать как раз тем путем, который я описал выше, в примере бат-файлов - через назначаемый GOTO. Полагаю, Вы согласитесь с тем, что любая другая реализация конвертора окажется много сложнее, а результат ее работы - дальше от исходного варианта. softwarer Названное, за исключением последнего пункта - с поправкой на мои неполные знания - отличает именно эту пару от всех или почти всех распространенных языков той поры. c127Если Вы посмотрите на языки действительно той поры (60-е годы), то наверняка увидите что они очень похожи. Я назвал те отличия, которые выделяют из. Тот же Алгол - наличие операторных блоков, предобъявление переменных, сильная типизация, вообще явный предок Паскаля. PL/I - своеобразный язык, но тоже скорее алгольного типа; в нем, кстати, присутствовала конструкция "арифметического цикла с условием" - не помню как записывалась, но по смыслу именно что Код: plaintext someCondition, естественно, задавался программистом. APL - особая вещь, пожалуй что равно далекая от всего перечисленного. Вот пример текста на нем (обратите внимание на операторы get и set): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. SIMULA - никогда не видел, не знаю, на что она похожа. LISP, опять-таки - совершенно особая вещь. Функциональность тут особо не при чем; R-LISP - вполне себе алгоритмический-процедурный, но его все равно ни с чем не спутаешь :) Хотя я не смотрел, может и ошибаюсь. Лисп не считается, он функциональный. Есть утверждение - с которым я согласен - что после того, как поработаешь на нескольких языках, почти любой новый становится просто комбинацией черт предыдущих. Но тем не менее, столь же легко и назвать различия, пусть они более тонкие, нежели "похожести". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 14:33 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingiz в любом интерпретаторе не надо обьявлять переменные. Глупость. Наиболее популярный нынче пример обратного - Java. tchingizкстати, perl удовлетворяет Вашей просьбе назвать язык, где бы имя переменной задавало тип. То есть собственного примера Вы привести не можете, берете из обсуждения. Кстати, напомню что в Перле вообще весьма специфичное понимание переменных; так, $a в нем с равной вероятностью может оказаться строкой, числом или объектом, а $a и @a, хоть и вроде разные вещи - но внутри оказываются двумя ипостасями одной переменной. tchingizГлобальные переменные жили в коммон областях. Они просто не назывались глобальными, но суть таже, отовсюду к ним был доступ. Не совсем так. Доступ к ним был не "отовсюду", а "отовсюду, откуда захотят его получить". В отличие от глобальных переменных, которые благодаря факту своего создания присутствуют в общей области видимости и никуда оттуда не денутся. Думаю, что бейсик был позже фортрана, Это так. а Вы пишите, что программа бейсика, в целом похожа на одну фортран программу. И это так. Не принято както отказываться от хороших качеств. Наследник бы наследовал хорошие качества. Хм. "Хорошие качества" - весьма обширная тема. В данном случае наследовали такое хорошее качество, как "простота", если не "тривиальность". В качестве сходного примера - Паскаль, как известно, строился на основе Алгола. Однако, отказался от алгольной возможности объявления переменных во вложенных операторных блоках; в Паскале локальные переменные можно объявлять только в заголовке подпрограммы. Если брать примеры посвежее - C++ отказался от элегантности и простоты C в пользу мощи; отказался от слабой типизации в пользу типизации сильной. java и C# дружно потеряли основное хорошее качество своего явного предшественника - множественное наследование, а заодно и от макросов. сомнительно Ваше утверждение softwarer>Фортран - предок бейсика Да, в общем, сомневайтесь если хотите. Правда, в первой же процитированной фразе Вы уверенно изрекли.. куда более сомнительное утверждение. вот язык ratfor (rational fortran) разработанный как препроцессор для фортрана под никсами уже обладал всеми атрибутами структурного программирования (циклы while, until, отсутствие меток и операторные скобки), Причем Фортран сам по себе также обладает всеми необходимыми для структурного программирования конструкциями, а названное скорее провоцирует заподозрить Вас в приверженности популярной благоглупости "структурное программирование - это отказ от GOTO". и все равно мог бы считаться наследником фортрана. Формальная грамматика ратфора представляла из себя 10-12 строчек. Это, простите, ересь. "Препроцессор" не может считаться наследником компилятора - в противном случае утилиту grep можно обозвать наследником "Войны и мира", по которой она делает поиск. Если же говорить о языке вида "препроцессор плюс собственно фортран", то я не вижу ничего, что помешает ему быть "наследником фортрана", но было бы интересно посмотреть на его грамматику из 10-12 правил. tchingizДля своей версии ратфора, я еще добавил операции ++, --, +=, -= и тд. И думаю это не изменило свойства фортрана быть предком ратфора от меня. )))))))) Осталось понять, к чему Вы это рассказали. Боюсь, единственная связь, которую я могу придумать - Вы пытаетесь опровергнуть мое утверждение методом "раз вот это - наследник, то не похожее на это - не наследник". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 16:21 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer Возможно, тут вопрос подхода. С моей точки зрения то, что может быть вынесено из языка, должно быть вынесено из языка - это собственно и есть "разгрузка". Тогда давайте уберем из С цикл while, сишного for достаточно. Кстати я бы так и поступил на месте авторов С. softwarer Другие неудачи - вычисляемый GOTO и арифметический IF как довольно неуклюжие замены case/switch. Объяснял уже, в тех задачах case/switch не используется почти никогда. Когда создавали фортран о нем никто не подозревал. Потом его ввели в язык. softwarer COMMON области как неуклюжие замены глобальных переменных (я бы сказал даже, не столько глобальных переменных, сколько конструкции record/struct. Структуру нетрудно передать параметром подпрограммы, в отличие от пятидесяти ее полей поодиночке - поэтому ее и передавали через common область). Однако Вы ниже совершенно справедливо утверждаете что COMMON это все-же не совсем глобальные переменные. softwarer Напрасное, с моей точки зрения, выделение трех (если не изменяет память) принципиально разных типов подпрограмм. В паскале тоже три: program, процедура и функция. softwarer Назначаемый GOTO - специфическая конструкция, мягко говоря не для "языка для непрограммистов". Назначаемых это вычисляемый? Неудобно, но почти никогда не используется, нетипичен для тех задач. Уже обсуждался. softwarer Замечательный оператор IMPLICIT :) Это тоже уже обсуждалось, экономит объявления переменных. softwarer Ну да. Переведите один в один subroutine f(n) real y(n) return end[/quote] Признаться, не понимаю этого фрагмента. Судя по Вашим словам, этот массив должен каким-то образом вернуться из подпрограммы, но каким - видимо, я либо тупой, либо слишком хорошо забыл Fortran. Нет, это пример того, что ошибку с освобождением памяти сделать труднее. softwarer Впрочем, согласитесь, "создание массива размерности N" переводится на Си совершенно элементарно. С заведением массива проблем нет, проблема есть с освобождением. softwarer Я не считаю, что отсутствие развитых циклов, например - лишнее. Арифметический цикл - хорошо, но стандартнейшая задача "арифметический цикл с условием досрочного выхода" - решается в PL/I, решается в паскале/си, но не в фортране. Вернее, если не ошибаюсь, в фортране она решается на уровне IF..GOTO - можно, в принципе но не лучший вариант. Еще раз: развитый цикл запутывает опртимизатор. К тому же ими почти никто не пользуется. Я не против развитых циклов, но в фортране они не нужны. GOTO неудобно, согласен, для выхода из цикла в поздних версиях фортрана был введен оператор типа break. softwarer Если говорить о вычислениях - давайте вспомним о такой стандартнейшем математическом приеме, как вычисление с переменным шагом (не помню, как это называется "по научному", но абсолютно стандартная вещь для задач типа "интегрирование с заданной точностью"). В Си это - тот же цикл for. В Паскале это - например, цикл while. В Фортране это - IF/GOTO. Или тот же do c выходом по условию. softwarer Код: plaintext Не мешает, только этого почему-то никто не делат. Пишут для общего случая. softwarer К чему я это - к тому, что у Фортрана как языка нет никаких особых преимуществ по оптимизации. Программы флоат вычислений, написанные на NDP фортране работал в 2 раза быстрее чем такие же на NDP С. NDP очень хороший компилятор. А так больше никаких преимуществ нет. Комплексные числа по-прежнему не вспоминаем. softwarer Все равно всеми возможностями цикла for никто не пользуется. "Отучаемся говорить за всех" (c) Неужели вы используете ВСЕ возможности оператора for? Как часто? softwarer Хм. Так если помните, эта часть беседы началась с фразы одного из присутствующих о полной прикладной победе Си. Я ответил на это, что лет двадцать назад это же могли бы сказать о Фортране - и были бы столь же корректны. Некорректное сравнение. Фортран никогда не продвигался как универсальный язык. softwarer Формальные параметры ОЧЕНЬ ХОРОШИЙ АРГУМЕНТ. ИМХО. Ваш аргумент с циклами по сравнению с ним совсем не в тему. Опять же ИМХО. Конечно, можно сойтись на имхах. Я бы сказал так: цикл - более "коренная", необходимая структура языка, нежели подпрограмма, следовательно и сходства-различия в них более важны с точки зрения похожести. Уже говорил, тогда паскаль ближе к бейсику чем фортран. Цикл простой и даже называется одинаково. softwarer Хм. Я не уверен, что понимаю Вас. В первую очередь: имеете ли Вы в виду именно параметры как таковые (то есть логическое противопоставление формальный-фактический), то ли Вы имеете в виду под формальными параметрами фортрановскую "передачу по ссылке". Первое. Второе - техника, первое - основы. softwarer Я бы сказал, параметры есть естественный атрибут подпрограмм; невозможно понять смысл подпрограмм, не поняв смысла их параметров. Именно об этом и речь, бейсиковцы их и не понимали. Подпрограммы (ИМХО) были, а параметров - не было. Программисты не привыкали к правильно думать. softwarer Позволю себе использовать Ваш аргумент: если из Фортрана "для простоты" убрали циклы, кроме тривиального, то в Бейсике развили эту идею и "для простоты" убрали "параметры подпрограмм" (с Вашей точки зрения) или "подпрограммы" (с моей). Цикл есть цикл, даже если он записывается как goto, от этого ничего не меняется. А если нет формальных параметров это все, их ничто не заменяет. softwarer Подчеркну на всякий случай: это не есть утверждение, которое я считаю верным. Это опровержение Вашей схемы рассуждения методом "от противного". Сравнение некорректное, нет опровержения. softwarer c127Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная. Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было. Ну да, сами же говорили о формальных параметрах. softwarer c127При чем тут шире-не шире, я такого не говорил. Я не думаю что бейсик какой-то особый наследник фортрана. Хм. Я думаю, что Бейсик - наследник Фортрана. Чингиз, а следом и Вы, решили поспорить с этим, выдвигая основным аргументом отсутствие одной из конструкций, существующих в Фортране - то есть то, что Бейсик не реализует одной из важных особенностей "предка". Поэтому я и сказал, что наследник вовсе не обязан быть "шире" предка; тезис "уже - значит, не наследник" не представляется мне бесспорно верным. Ключевое слово - важной. Опять вопрос классификации. softwarer Они появились примерно в одно время, я правда не видел тот бейсик. Между ними - семь лет разницы. По утверждению создателя (можно найти точную цитату), Бейсик создавался как учебный язык для студентов, как ступенька для перехода на более мощные Фортран и Алгол (что вполне обосновывает его относительную убогость). Ну и если сравнить из Фортрана и Алгола, на кого больше похож Бейсик - ответ, имхо, совершенно однозначен. В противопоставление созданному позже учебному Паскалю, похожему именно на Алгол. Похож - не значит наследник. Да и похож не сильно. Даже если бейсик и создавался с оглядкой на фортран (что возможно), то в результате сходство между ними к моменту реанимации бейсика в начале 80-х оказалось не больше чем между паскалем и С. Давайте для экономии времени я сформулирую утверждение: я уверен, что если мы с Вами согласуем список формальных признаков (наличие тех или иных конструкций и концепций), то из "прочих основных языков того времени" фортран окажется самым близким или по крайней мере одним из самых близких. softwarer Не соглашусь. К тому моменту существовало порядка десятка "основных" языков, тех, названия которых сейчас можно вспомнить не напрягаясь: FORTRAN, ALGOL, APL, SIMULA, PL/I, COBOL, LISP. И на самом деле тогда был некий взрыв языкотворчества; раскрывалась новая область, из которой до нас дошли наиболее удачные либо наиболее удачливые представители. Главное что фортран тогда был далеко впереди по использованию. Наука, гонка вооружений, ракеты, везде нужны были рассчеты. Все остальные плелис в хвосте. Появились другие задачи - появились другие языки, фортран утратил первое место потому что утратила первое место та ниша, в которой он сидел. softwarer Да не сказал бы. Признаться, не помню как в ALGOL и PL/I - может, это было обычно в те времена - но по сравнению с более поздними временами эта схема раритетна. В классическом паскале она достаточно похожа, но все-таки введено важное понятие "файловой переменной"; в результате, например, файл можно передать параметром в подпрограмму. В Си и в более поздних версиях Паскаля сделано правильнее: работа с файлами убрана на уровень библиотек, функций/классов с уровня операторов языка. Номер файла тоже можно передавать в подпрограмму. Библиотеки есть везде. По-прежнему не вижу разницы. С непроцедурными языками сравнивать не нужно. Во-первых это и тогда и сейчас очень большая экзотика, а во-вторых бейсик процедурный, по-видимому автор отдавал себе отчет что создает процедурный язык в этом до начала создания языка, как он может быть похож на непроцедурный язык? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 23:43 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer и все равно мог бы считаться наследником фортрана. Формальная грамматика ратфора представляла из себя 10-12 строчек. Это, простите, ересь. "Препроцессор" не может считаться наследником компилятора - в противном случае утилиту grep можно обозвать наследником "Войны и мира", по которой она делает поиск. Если же говорить о языке вида "препроцессор плюс собственно фортран", то я не вижу ничего, что помешает ему быть "наследником фортрана", но было бы интересно посмотреть на его грамматику из 10-12 правил. 1 ересь про препроцессор Вы придумали сами. /* С другой стороны, компилятор можно рассматривать как препроцессор к ассемблеру. Как и был сделан си - компилятор до эры персоналок. (работал в 3 или 4 или 5 прохода, на предпоследнем проходе вызывался ассемблер) Какая теоретическая причина может не позволить препроцессору фортрана не быть наследником препроцессора ассемблера ума не приложу */ ))))))) ну да, Я обсуждал язык, а не реализацию. грамматика была для yacc - lex. Разработал его Брайон Керниган - автор Си. а на нашей машине был фортран4 (в котором не было операторных скобок ) и не было фортрана77 (в котором они, возможно, были) . Так что лучше меня заподозрить в такой благоглупости, как желание использовать удобные инструменты. гугль нашел ратфор сразу. вот он http://sepwww.stanford.edu/software/ratfor.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 01:21 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer tchingiz в любом интерпретаторе не надо обьявлять переменные. Глупость. Наиболее популярный нынче пример обратного - Java. ... tchingizГлобальные переменные жили в коммон областях. Они просто не назывались глобальными, но суть таже, отовсюду к ним был доступ. Не совсем так. Доступ к ним был не "отовсюду", а "отовсюду, откуда захотят его получить". В отличие от глобальных переменных, которые благодаря факту своего создания присутствуют в общей области видимости и никуда оттуда не денутся. .... а Вы пишите, что программа бейсика, в целом похожа на одну фортран программу. И это так. . Ява - сомнительный контрпример. Она далеко не интрепретатор. Интерпретатор (как бейсик ) можно было использовать для вычисления каждой отдельной строчки. глобальные переменные. не поленился почитать в справочнике Болски язык программирования си. Оказалось определения глобальных переменных в си противоречит Вашему мнению. к глобальным переменным в си, тоже доступ был не отовсюду. Будем считать, что Вам виднее. Насколько я помню, в старых бейсиках определение глобальных переменых совпадало с Вашим и было отлично от фортрановского. похожесть. это не так я работал на фортране, на бейсике, сишарпе и перле. фортран похож на бейсик так же, как сишарп на перл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 01:36 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127 softwarer - В бейсике, как и в фортране, длина метки была ограничена пятью символами :)) (в стандартных реализациях для мини-ЭВМ). Шутку понял. В бейсике это не метка, это номер (адрес, идентификатор) строки в программе. Номера идут по-порядку. А вот в фортране это действительно метка. В фортране метки в разных подпрограммах могли дублироваться, а в бейсике номера строк - нет. наверно, не забуду никогда мудрую строчку из руководства по бейсику, написанного в 88 году (уже при живом паскале и си) : "когда нумеруете строчки программы, делайте это с шагом 10, чтобы была возможность вставлять новые строчки при изменении программы. " явный наследник фортрана. и очень удобно обьяснять студентам и домохозяйкам, в фортране же ничего подобного обьяснить нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 01:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Блинский блинКуда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... Он что такой продвинутый что всем вынь да полож? Чем VB не угодил к примеру? Может потому что паскаль - язык студентов, коих и развелось пруд пруди? Не знаю как там у вас, а у нас во Владивостоке, куда ни глянь все Oracle, С++, да 1С. С трудом работу программиста Delphi и VB нашла (зато хорошую). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 09:58 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Аленочка Блинский блинКуда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... Он что такой продвинутый что всем вынь да полож? Чем VB не угодил к примеру? Может потому что паскаль - язык студентов, коих и развелось пруд пруди? Не знаю как там у вас, а у нас во Владивостоке, куда ни глянь все Oracle, С++, да 1С. С трудом работу программиста Delphi и VB нашла (зато хорошую). Молодец ! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 10:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127 softwarerВозможно, тут вопрос подхода. С моей точки зрения то, что может быть вынесено из языка, должно быть вынесено из языка - это собственно и есть "разгрузка". Тогда давайте уберем из С цикл while, сишного for достаточно. Кстати я бы так и поступил на месте авторов С. Не понял логики. "Разгрузкой" было бы "давайте уберем из C цикл вообще". Насчет "Вы бы так и поступили" - вполне возможно, именно поэтому Вы и ратуете за фортран :) Постараюсь донести свою мысль максимально аккуратно. Итак, если у нас есть эквивалентные оператор WRITEFILE и функция WriteFile, второе представляется мне более удачным решением, поскольку это "отъемлимая", если можно так выразиться, часть языка, часть, объективно склонная к изменениям; стандартизируя ее в языке, мы тем самым душим ее развитие. Это хорошо видно на примере паскалевских файлов - сегодня работать с ними неудобно, незачем и я бы сказал, глупо; виртовские методы поддерживаются только для совместимости. В то же время я приветствую уместное разнообразие правильных способов выражения мысли; скажем, несколько версий функции WriteFile. Цикла for действительно было бы достаточно, но - ключевым достоинством Си является "четкость и лаконичность выражения мысли", чему наличие while весьма способствует. Собственно, если бы его не было - все подряд делали бы макрос while, делающий то же самое, что вряд ли было бы хорошо. c127Объяснял уже, в тех задачах case/switch не используется почти никогда. Когда создавали фортран о нем никто не подозревал. Потом его ввели в язык. Хм. Я кажется уже объяснял, что я нисколько не нападаю на язык, в том плане что абсолютно не стремлюсь доказать "он плохой". Я отвечаю на Ваш же вопрос. Далее, о "тех" задачах. Видите ли, вышло так, что моя мама много лет именно на Фортране делала довольно сложные вещи - обсчет и полунатурное моделирование для авиации, еще кое-что. Я, поскольку в те годы активно интересовался всем связанным, некоторые фрагменты видел/обсуждал. И не сказал бы, что это "тупой прямой обсчет". Да, решение стандартной задачи, какой-нибудь системы линейных уравнений, делается довольно прямо. Но это решение - только кирпичик, из которого строится собственно программа. c127 softwarer COMMON области как неуклюжие замены глобальных переменных (я бы сказал даже, не столько глобальных переменных, сколько конструкции record/struct. Структуру нетрудно передать параметром подпрограммы, в отличие от пятидесяти ее полей поодиночке - поэтому ее и передавали через common область). Однако Вы ниже совершенно справедливо утверждаете что COMMON это все-же не совсем глобальные переменные. Не совсем. Я и здесь утверждаю то же самое :) Я так полагаю, что назвал две основных причины их применения. Но я полагаю, что для обоих случаев существуют более удачные подходы. c127 softwarer Напрасное, с моей точки зрения, выделение трех (если не изменяет память) принципиально разных типов подпрограмм. В паскале тоже три: program, процедура и функция. Program тут не при чем. А разницу между процедурой и функцией весьма стремительно сгладили, что пожалуй является лучшим аргументом в пользу того, что изначальное решение сделать ее было неудачным. c127 softwarer Назначаемый GOTO - специфическая конструкция, мягко говоря не для "языка для непрограммистов". Назначаемых это вычисляемый? Нет, назначаемый это назначаемый Код: plaintext 1. 2. 3. c127Неудобно, но почти никогда не используется, нетипичен для тех задач. Уже обсуждался. Я бы не сказал, что он не использовался. Использовался, и активно. Но пал первой жертвой структурного программирования. c127Это тоже уже обсуждалось, экономит объявления переменных. Хм. Никто не говорит, что "абсолютно бесполезен". Я, если помните, отвечаю на вопрос о перегруженности. И с моей точки зрения, "перегрузить программу объявлениями переменных" - куда более полезных вид этого занятия. c127Нет, это пример того, что ошибку с освобождением памяти сделать труднее. А, вот Вы о чем :) Это актуально если сравнивать ручное программирование. Но именно эта фраза возникла в контексте конвертора Фортран -> Си - а в нем "ошибку с освобождением памяти" сделать столь же трудно. В ручном кодировании, безусловно, об этом нужно помнить, но здесь у каждого языка свои фокусы - вспомним, например, классический фортрановский прикол с изменением значения константы. c127Еще раз: развитый цикл запутывает опртимизатор. Еще раз: не запутывает. А вот "имитация развитого цикла подручными средствами" - та да, чтобы ее распутать, нужно потрудиться. c127К тому же ими почти никто не пользуется. Хм. c127GOTO неудобно, согласен, для выхода из цикла в поздних версиях фортрана был введен оператор типа break. Это утверждение выглядит странно, если сопоставить его с более ранним "я бы оставил в Си только FOR, убрав WHILE". BREAK - это одна из форм оператора GOTO. Всей разницы - экономия нескольких символов на метке. Это ровно такая же приятная мелочь, синтаксическое удобство, как и сишный цикл while. То неудобство, о котором шла речь - в Фортране часто приходилось применять GOTO как раз для эмуляции отсутствующих конструкций: операторного блока и сложного цикла. Именно поэтому фортран-программы приводились в пример в работах по структурному программированию: они держали абсолютный рекорд по частоте употребления GOTO; если мне не изменяет память, у одного из классиков упомянут проект, в котором GOTO встречался в каждой третьей строке выполняемого кода. c127 softwarer Если говорить о вычислениях - давайте вспомним о такой стандартнейшем математическом приеме, как вычисление с переменным шагом (не помню, как это называется "по научному", но абсолютно стандартная вещь для задач типа "интегрирование с заданной точностью"). В Си это - тот же цикл for. В Паскале это - например, цикл while. В Фортране это - IF/GOTO. Или тот же do c выходом по условию. С каким выходом и по какому условию? Еще раз: цикл с переменным шагом . Примерно так: Код: plaintext Не мешает, только этого почему-то никто не делат. Пишут для общего случая. Никак не комментируя истинность этого утверждения - это означает то, что "для общего случая" оптимизировать выгоднее. То есть не "запутывает оптимизатор", а как раз "оптимизация do есть частный случай либо шаг в сторону". softwarer К чему я это - к тому, что у Фортрана как языка нет никаких особых преимуществ по оптимизации. Программы флоат вычислений, написанные на NDP фортране работал в 2 раза быстрее чем такие же на NDP С Как факт - верю. Но сомневаюсь, что Вы покажете мне неустранимую причину этого. Скорее всего, в оптимизаторе C ставили другие задачи. . NDP очень хороший компилятор. А так больше никаких преимуществ нет. Комплексные числа по-прежнему не вспоминаем. Признаться, не смотрел всерьез этот вопрос, поэтому мне нечего вспомнить. Не очень вижу, за счет чего встроенный тип комплексных чисел будет оптимизиться сильно лучше, чем пользовательский, но и не решусь возражать. Неужели вы используете ВСЕ возможности оператора for? Как часто? Что именно Вы называете "все возможности"? Как простой эксперимент - я перебрал циклы for в нескольких модулях, прямо сейчас открытых у меня в IDE. Где-то четвертая или пятая часть из них содержит "навороты". с127 softwarer Хм. Так если помните, эта часть беседы началась с фразы одного из присутствующих о полной прикладной победе Си. Я ответил на это, что лет двадцать назад это же могли бы сказать о Фортране - и были бы столь же корректны. Некорректное сравнение. Фортран никогда не продвигался как универсальный язык. Да и Си тоже - до тех пор, пока не пошел маркетинг. А под маркетинг могло попасть что угодно. Такое впечатление, что Вы принципиально не осознаете логику доказательства "от противного". Я показываю "явно сомнительный пример, похожий на названный" - а Вы тут же начинаете оспаривать именно мой пример. Ну, допустим, оспорите. Что Вы этим доказываете - то, что Си универсальный язык и практически все приложения ближайших лет будут написаны на нем? Именно это утверждал автор, именно на это я возражал, именно это Вы вроде как получается отстаиваете - но в то же время в других фразах Вы явно с этим не согласны. Уже говорил, тогда паскаль ближе к бейсику чем фортран. Цикл простой и даже называется одинаково. Вашу мысль стоит представить в табличном виде. Есть ЯзыкАриф. цикл.Расш. ариф. циклЦикл с предусловиемЦикл с постусловиемBASICFOR---FORTRANDO---PASCALFOR-WHILEREPEATCFORFORWHILEDOPL/I++?? Итак, глядя на эту таблицу, мы видим, что Бейсик больше всего похож на Паскаль, поскольку циклы называются одинаково :) И кстати - почему именно на Паскаль? В Си цикл тоже называется FOR. При этом Фортрановский и Бейсиковский цикл умеют одинаково (что в Вашей логике не аргумент), а вот сравнение Паскалевского с Бейсиковским интересно: каждый из них умеет то, чего не умеет другой. softwarer Я бы сказал, параметры есть естественный атрибут подпрограмм; невозможно понять смысл подпрограмм, не поняв смысла их параметров. Именно об этом и речь, бейсиковцы их и не понимали. Подпрограммы (ИМХО) были, а параметров - не было. Программисты не привыкали к правильно думать. Чем же это подпрограммы? Если говорить в терминах Си, это пара setjmp/goto (аналог GOSUB) и longjmp (аналог RETURN). Это даже слабее, чем ассемблерные подпрограммы. Цикл есть цикл, даже если он записывается как goto, от этого ничего не меняется. А если нет формальных параметров это все, их ничто не заменяет. Да бросьте. Точно так же заменяется. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Сравнение некорректное, нет опровержения. Не могу ничего ответить, поскольку из оставленной цитаты уже не ясно, о чем собственно шла речь. softwarer c127Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная. Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было. Ну да, сами же говорили о формальных параметрах. Да. Я не считаю "Запорожец" удобным только из-за отсутствия "Мерседеса". Это был сомнительный сам по себе инструмент, но реализованные в языке альтернативы были еще хуже. softwarer Чингиз, а следом и Вы, решили поспорить с этим, выдвигая основным аргументом отсутствие одной из конструкций, существующих в Фортране - то есть то, что Бейсик не реализует одной из важных особенностей "предка". Ключевое слово - важной. Опять вопрос классификации. Отнюдь, не ключевое. Для примера - покажите ложное из следующих трех утверждений: 1. С# есть наследник C++ 2. Важной особенностью C++ является множественное наследование 3. C# не допускает множественного наследования. Похож - не значит наследник. Да и похож не сильно. Полагаю, незачем спорить о смысле слова "наследник". Ну а насчет похожести - если автор позиционировал как "учебный язык для перехода на", то видимо таки считал достаточно похожим. Получилось ли - можно обсуждать, но само намерение... Главное что фортран тогда был далеко впереди по использованию. Наука, гонка вооружений, ракеты, везде нужны были рассчеты. Все остальные Я не понимаю, что Вы хотите обосновать. Вы выразились в том смысле, что других языков не было, а какие были - во-первых были похожи на фортран, а во-вторых, автор их не знал. Я показал что были, и постарался обосновать то, что были похожи куда меньше. Насчет "не знал" - сомнительно, но вряд ли есть смысл обсуждать, поскольку трудно проверить. softwarer Да не сказал бы. Признаться, не помню как в ALGOL и PL/I - может, это было обычно в те времена - но по сравнению с более поздними временами эта схема раритетна. В классическом паскале она достаточно похожа, но все-таки введено важное понятие "файловой переменной"; в результате, например, файл можно передать параметром в подпрограмму. В Си и в более поздних версиях Паскаля сделано правильнее: работа с файлами убрана на уровень библиотек, функций/классов с уровня операторов языка. Номер файла тоже можно передавать в подпрограмму. И так было изначально? Хм, возможно здесь меня подводит память. С непроцедурными языками сравнивать не нужно. Во-первых это и тогда и сейчас очень большая экзотика, а во-вторых .... Хм. Возможно, я неправильно понимаю смысл "процедурного" языка. В том, на что Вы отвечаете, названы ALGOL, PL/I, Pascal, С. Кто из них менее процедурен, чем бейсик, и почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 14:21 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Softwarer ... Мне кажется что для C++ циклы for и while - идентичны. По крайней мере мне удавалось по шаблону переходить от while к for и наоборот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 14:54 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
maytonМне кажется что для C++ циклы for и while - идентичны. Теоретически - да. Но их идентичность не особо жизненная; скажем, чтобы справится со следующим упрощенным примером: Код: plaintext конвертору придется либо сгенерить очень плохой, некрасивый код, либо использовать goto. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 15:41 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizнаверно, не забуду никогда мудрую строчку из руководства по бейсику, написанного в 88 году (уже при живом паскале и си) : "когда нумеруете строчки программы, делайте это с шагом 10, чтобы была возможность вставлять новые строчки при изменении программы. Чем же она мудрая? Учитывая, что существовал замечательный оператор RENUMBER. А глупостей можно откуда угодно и сколько угодно нацитировать, дефицита не предвидится. явный наследник фортрана. Дык. Там для той же цели совали перфокарту между двумя другими. Перфокарты иногда подкрашивали или иначе выделяли - например, чтобы легко и просто убрать из колоды отладочную печать или заменить подпрограмму на альтернативную версию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 15:50 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizЯва - сомнительный контрпример. Она далеко не интрепретатор. Видимо, она неизвестный науке зверь. Да, правы были классики: "если факты противоречат теории - тем хуже для фактов". tchingizИнтерпретатор (как бейсик ) можно было использовать для вычисления каждой отдельной строчки. Как минимум, очень неудачная формулировка. Честно говоря, хочется назвать ее бредовой. Интересно было бы посмотреть, как интерпретатор бейсика вычислит вполне себе синтаксически верную строчку Код: plaintext или хотя бы столь же синтаксически верную Код: plaintext Если же говорить о вычислении самостоятельных частей программы, существующая ява вполне способна их вычислить. tchingizне поленился почитать в справочнике Болски язык программирования си. Оказалось определения глобальных переменных в си противоречит Вашему мнению. к глобальным переменным в си, тоже доступ был не отовсюду. Будем считать, что Вам виднее. Насколько я помню, в старых бейсиках определение глобальных переменых совпадало с Вашим и было отлично от фортрановского. Не совсем так. В Си введена новая по сравнению с Фортраном и Бейсиком логическая единица кода - файл. Введена именно в язык, следствием чего явилось ограничение области видимости и директива extern. В Фортране, если мне не изменяет память, многофайловость поддерживалась компилятором (посредством библиотек), но логически программа являлась одним файлом. Соответственно, если взять Си-программу, состоящую из одного логического файла (который может включать другие по #include), то в ней глобальные переменные ведут себя именно таким вот, "бейсиковским" образом. Здесь также важно помнить об отличии глобальной переменной и локальной статической. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 16:25 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer c127 softwarerВозможно, тут вопрос подхода. С моей точки зрения то, что может быть вынесено из языка, должно быть вынесено из языка - это собственно и есть "разгрузка". Тогда давайте уберем из С цикл while, сишного for достаточно. Кстати я бы так и поступил на месте авторов С. Не понял логики. "Разгрузкой" было бы "давайте уберем из C цикл вообще". Насчет "Вы бы так и поступили" - вполне возможно, именно поэтому Вы и ратуете за фортран :) Я ратую за фортран только в его области - в рассчетных задачах задачах с флоат арифметикой. Там ничего лучшего не придумали. Нигде больше его использовать не нужно. softwarer Постараюсь донести свою мысль максимально аккуратно. Итак, если у нас есть эквивалентные оператор WRITEFILE и функция WriteFile, второе представляется мне более удачным решением, поскольку это "отъемлимая", если можно так выразиться, часть языка, часть, объективно склонная к изменениям; У паскаля та же проблема что и у фортрана. Тут С со своими библиотеками скорее исключение, а не правило. softwarer Цикла for действительно было бы достаточно, но - ключевым достоинством Си является "четкость и лаконичность выражения мысли", чему наличие while весьма способствует. Собственно, если бы его не было - все подряд делали бы макрос while, делающий то же самое, что вряд ли было бы хорошо. Цикл while(предикат){...} полностью эквивалентен цииклу for(;предикат;){...}. Даже символов получается одинаковое количество. Поэтому я не понимаю что в данном случае дает введение дополнительного оператора в язык, никакого выигрыша в смысле лаконичности не получается. softwarer Далее, о "тех" задачах. Видите ли, вышло так, что моя мама много лет именно на Фортране делала довольно сложные вещи - обсчет и полунатурное моделирование для авиации, еще кое-что. Я, поскольку в те годы активно интересовался всем связанным, некоторые фрагменты видел/обсуждал. И не сказал бы, что это "тупой прямой обсчет". Да, решение стандартной задачи, какой-нибудь системы линейных уравнений, делается довольно прямо. Но это решение - только кирпичик, из которого строится собственно программа. Да, но эти кирпичики жрут основное время счета. Их удобно писать на фортране. Операторы switch это в большинстве логика работы программы (это нестрого), но в рассчетах они встречаются редко. Логику нужно писать, например, на С. Когда связка фортрана с С была проблемой, все писалось на одном языке, по-видимому поэтому в Вашем примере в фортране встречалось много конструкций эквивалентных switch. softwarer Program тут не при чем. А разницу между процедурой и функцией весьма стремительно сгладили, что пожалуй является лучшим аргументом в пользу того, что изначальное решение сделать ее было неудачным. Сгладили только в С и всем что от него пошло, типа джавы, пошарпаного С, С++ и пр. softwarer Это актуально если сравнивать ручное программирование. Но именно эта фраза возникла в контексте конвертора Фортран -> Си - а в нем "ошибку с освобождением памяти" сделать столь же трудно. Я говорил о ручном программировании, ясно что правильный конвертор все проконвертит правильно, но я думаю о себе. Ошибка основная, если ее убрать то С станет вполне даже приличным языком. softwarer В ручном кодировании, безусловно, об этом нужно помнить, но здесь у каждого языка свои фокусы - вспомним, например, классический фортрановский прикол с изменением значения константы. Освобождение памяти более серьезная ошибка и более часто встречающаяся. А что там с изменение констаны, это оператор DATA? Я константы всегда объявлял константы как parameter, вроде поменять нельзя, но возможно ошибаюсь. Но это поздние версии фортрана. softwarer c127GOTO неудобно, согласен, для выхода из цикла в поздних версиях фортрана был введен оператор типа break. Это утверждение выглядит странно, если сопоставить его с более ранним "я бы оставил в Си только FOR, убрав WHILE". Речь шла только о сишном for, он эквивалентен while, в фортране, паскале while нужен, там цикл его не заменяет. softwarer BREAK - это одна из форм оператора GOTO. Всей разницы - экономия нескольких символов на метке. Это ровно такая же приятная мелочь, синтаксическое удобство, как и сишный цикл while. GOTO запутывает оптимизатор, оптимизатор не знает куда будет переход. BREAK учесть легче, это частный случай GOTO. Та же история что и с циклами, чем более общий случай тем труднее его оптимизировать. softwarer То неудобство, о котором шла речь - в Фортране часто приходилось применять GOTO как раз для эмуляции отсутствующих конструкций: операторного блока и сложного цикла. Именно поэтому фортран-программы приводились в пример в работах по структурному программированию: они держали абсолютный рекорд по частоте употребления GOTO; если мне не изменяет память, у одного из классиков упомянут проект, в котором GOTO встречался в каждой третьей строке выполняемого кода. Если не ошибаюсь на момент создания фортрана структурного программирования не было и близко. Когда концепция появилась фортран подрехтовали, теперь на нем легко можно программировать структурно без GOTO. Для этого потребовалось 3 оператора: switch, while, break. Не так много. softwarer Еще раз: цикл с переменным шагом . Примерно так: Код: plaintext Вот и попробуйте соптимизировать такой цикл. Компилятор вообще не знает что там происходит. По этой причине вообще циклы не оптимизирует на всякий случай. Шучу конечно, но доля правды есть. А в фортране цикл определяется таким образом, что на момент входа в цикл программа знает сколько раз он будет выполняться. Единственный способ прервать - опрератор break, который в языке появился. А goto компилятор запутывает, его использовать в этой ситуации не рекомендуется. И для которого из циклов легче написать оптимизатор по-Вашему? softwarer Программы флоат вычислений, написанные на NDP фортране работал в 2 раза быстрее чем такие же на NDP С Как факт - верю. Но сомневаюсь, что Вы покажете мне неустранимую причину этого. Скорее всего, в оптимизаторе C ставили другие задачи. Неустранимой причины конечно же нет, все работаем на одной и той же машине Поста, но вот технические есть. Как результат в книгах по фортрану (например в книге "Оптимизация в фортране", автора не помню, книги нет под рукой) советовалось не выносить повторяющиеся вычисления из цикла с целью оптимизации, поскольку компилятор их найдет и вынесет сам и сделает это лучше, а вот компиляторы по С вроде очень часто не выносят и вычисляют каждый раз. Это с точностью до слов моего коллеги который любит лазить по ассемблерным кодам, я сам все никак не соберусь посмотреть. softwarer . NDP очень хороший компилятор. А так больше никаких преимуществ нет. Комплексные числа по-прежнему не вспоминаем. Признаться, не смотрел всерьез этот вопрос, поэтому мне нечего вспомнить. Не очень вижу, за счет чего встроенный тип комплексных чисел будет оптимизиться сильно лучше, чем пользовательский, но и не решусь возражать. А что тут смотреть, в С типа complex нет. А лучше за счет того что: 1) программа где complex нужен получается компактнее, 2) библиотеки оптимизирует производитель компилятора а не я, а это кроме умножения-деления еще и все функции типа sin-cos-exp.... softwarer с127 softwarer Хм. Так если помните, эта часть беседы началась с фразы одного из присутствующих о полной прикладной победе Си. Я ответил на это, что лет двадцать назад это же могли бы сказать о Фортране - и были бы столь же корректны. Некорректное сравнение. Фортран никогда не продвигался как универсальный язык. Да и Си тоже - до тех пор, пока не пошел маркетинг. А под маркетинг могло попасть что угодно. Согласен, маркетинг штука страшная. Но во времена господства фортрана такой маркетинге никому не мог и присниться. К тому же так оказалось что С гораздо ближе к универсальному языку чем фортран, хоть и создавался совсем с другими целями. Мне он очень нравится. Если еще утечку памяти побороть, то вообще бы все было хорошо. Но как всякое универсальное средство С проигрывает специальным в их узких областях. softwarer Уже говорил, тогда паскаль ближе к бейсику чем фортран. Цикл простой и даже называется одинаково. Вашу мысль стоит представить в табличном виде. Есть Это была шутка, типа Ваша логика, доведенная до абсурда. softwarer И кстати - почему именно на Паскаль? В Си цикл тоже называется FOR. Потому что в С цикл for это нечто сложное, а у всех остальных - простое. softwarer При этом Фортрановский и Бейсиковский цикл умеют одинаково (что в Вашей логике не аргумент), а вот сравнение Паскалевского с Бейсиковским интересно: каждый из них умеет то, чего не умеет другой. И что же это в цикле у паскаля такое, что не умеет фортрановский цикл? softwarer Чем же это подпрограммы? Если говорить в терминах Си, это пара setjmp/goto (аналог GOSUB) и longjmp (аналог RETURN). Это даже слабее, чем ассемблерные подпрограммы. Опять речь о терминологии. Ладно, пусть нет подпрограмм, тогда это делает бейсик еще менее похожим на фортран. softwarer Цикл есть цикл, даже если он записывается как goto, от этого ничего не меняется. А если нет формальных параметров это все, их ничто не заменяет. Да бросьте. Точно так же заменяется. Это технически, а с точки зрения логики и понимания это существенная разница. Параметры это следующий после подпрограмм типа GOSUB шаг в абстрактном мышлении. softwarer softwarer Чингиз, а следом и Вы, решили поспорить с этим, выдвигая основным аргументом отсутствие одной из конструкций, существующих в Фортране - то есть то, что Бейсик не реализует одной из важных особенностей "предка". Ключевое слово - важной. Опять вопрос классификации. Отнюдь, не ключевое. Это для меня оно ключевое. Я же говорю, вопрос классификации, тут спорить сложно, она у каждого почти всегда своя. softwarer Номер файла тоже можно передавать в подпрограмму. И так было изначально? Хм, возможно здесь меня подводит память. Не знаю как оно было изначально, но в фортране 77 уже можно было по-моему. softwarer Хм. Возможно, я неправильно понимаю смысл "процедурного" языка. В том, на что Вы отвечаете, названы ALGOL, PL/I, Pascal, С. Кто из них менее процедурен, чем бейсик, и почему? Все одинаково процедурны. А вот ЛИСП и АПЛ (по-моему), которые Вы вспоминали, не процедурные. Но на момент придумывания бейсика (середина 60-х) 1) паскаля не было, 2) у алгола были проблемы с комрилятором, либо же компилятора не было вообще, точно не помню, 3) ПЛ/1 не знаю был ли, может тоже не было. Чтоб не ходить по кругу в вопросе о бейсике как наследнике фортрана предлагаю определиться. Я считаю что чтобы язык программирования D назвать наследником языка F необходимо выполнение двух условий: 1) авторы языка должны в явном виде заявить что D создавался на основе F 2) в момент создания D должен быть нацелен на решение тех же задач что и F В нашем случае условие 1) возможно выполняется, возможно нет, я исследований не проводил. Но вот условие 2) не выполняется наверняка, например потому что по Вашему утверждению бейсик создавался как язык обучения, в момент создания во флоат-вычислениях не был конкурентом фортрана даже теоретически. Поэтому бейсик НАСЛЕДНИКОМ фортрана назвать нельзя. Его можно назвать потомком, ответвлением, но не наследником. Если говорить о лишних и неудачных конструкциях в фортране, то они наверняка есть. Но все познается в сравнении, если посмотреть на другие языки, то там их как правило несравнимо больше, если фортран тут как-то выделяется, то только в лучшую сторону по-моему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 00:04 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer Соответственно, если взять Си-программу, состоящую из одного логического файла (который может включать другие по #include), то в ней глобальные переменные ведут себя именно таким вот, "бейсиковским" образом. 1 Ваше утверждение было безусловным "отовсюду", а в примере условие. 2 и даже в Вашем примере. если разместить глобальную переменную внизу файла, чтото мне подсказывает, что ее не будет видно "ниоткуда" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 00:44 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer Дык. Там для той же цели совали перфокарту между двумя другими. Перфокарты иногда подкрашивали или иначе выделяли - например, чтобы легко и просто убрать из колоды отладочную печать или заменить подпрограмму на альтернативную версию. идея рассматривать цвет перфокарт как свойство языка, и говорить что другой язык наследует имеено это свойство - как минимум очень неудачная. я бы назвал ее бредовой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 00:47 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer tchingizЯва - сомнительный контрпример. Она далеко не интрепретатор. Видимо, она неизвестный науке зверь. Да, правы были классики: "если факты противоречат теории - тем хуже для фактов". Насколько мне известно честных промышленных интерпретаторов в настоящий момент не существует. Они все псевдокомпиляторы в P-код ;) авторЦикл while(предикат){...} полностью эквивалентен цииклу for(;предикат;){...}. Даже символов получается одинаковое количество. Поэтому я не понимаю что в данном случае дает введение дополнительного оператора в язык, никакого выигрыша в смысле лаконичности не получается. Потому-что while настолько часто используется, что все равно нашелся бы какой нибудь ...день, которому он понадобился бы из эстетических соображений. И он разумеется забубенил бы его define-ом. А с макросами и без того проблем хватает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 08:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127Сгладили только в С и всем что от него пошло, типа джавы, пошарпаного С, С++ и пр. В том-же Паскале, любую функцию без всякого вреда для здоровья можно вызывать как процедуру. В той-же Аде процедуры и функции две больших разницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 08:34 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
авторНасколько мне известно честных промышленных интерпретаторов в настоящий момент не существует. Они все псевдокомпиляторы в P-код ;) это очень смелое заявление. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 10:30 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Угу, назовите хоть один ? Лично я не знаю. Слово против слова ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 10:35 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
да хоть тикль :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 10:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Поймали, не помню как он работает. Но сомнительно, что он каждый раз парсит каждую строку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 10:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
для меня "интерпретатор" значит следующее: исходник где строка 1- синтаксически правильна, а вторая - нет частично работает Код: plaintext 1. fff выводится а дальше -ошибка. Думаю, компиляторы p-кода должны сразу ругнуться. Вот python или perl в такой ситуации действительно выдадут ошибку сразу (видимо, во время пресловутой компиляции бинарного кода) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 10:51 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
в целом логично :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 11:18 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer Постараюсь донести свою мысль максимально аккуратно. Итак, если у нас есть эквивалентные оператор WRITEFILE и функция WriteFile, второе представляется мне более удачным решением, поскольку это "отъемлимая", если можно так выразиться, часть языка, часть, объективно склонная к изменениям; У паскаля та же проблема что и у фортрана. Тут С со своими библиотеками скорее исключение, а не правило. У оригинального - безусловно. И от этого быстро стали уходить. Подход Си на тот период, безусловно, был на голову впереди прочих. Цикл while(предикат){...} полностью эквивалентен цииклу for(;предикат;){...}. Даже символов получается одинаковое количество. Поэтому я не понимаю что в данном случае дает введение дополнительного оператора в язык, никакого выигрыша в смысле лаконичности не получается. OK. Давайте считать, что я вижу. Да, но эти кирпичики жрут основное время счета. Их удобно писать на фортране. Операторы switch это в большинстве логика работы программы (это нестрого), но в рассчетах они встречаются редко. Логику нужно писать, например, на С. Когда связка фортрана с С была проблемой, все писалось на одном языке, по-видимому поэтому в Вашем примере в фортране встречалось много конструкций эквивалентных switch. Признаться, не вижу смысла по столь мелкому поводу разводить зоопарк языков. Сгладили только в С и всем что от него пошло, типа джавы, пошарпаного С, С++ и пр. Отнюдь. Вы снова выдвигаете аргумент в стиле "потому что называется одинаково". Я все же предлагаю смотреть глубже; иначе придется, например, считать, что Рапира не имеет ничего общего с Фокалом (или из чего там ее сотворили), а Фотон - с Multi Edit-ом. Я говорил о ручном программировании, ясно что правильный конвертор все проконвертит правильно, но я думаю о себе. Ошибка основная, если ее убрать то С станет вполне даже приличным языком. По большому счету она уже давно убрана :) softwarer В ручном кодировании, безусловно, об этом нужно помнить, но здесь у каждого языка свои фокусы - вспомним, например, классический фортрановский прикол с изменением значения константы. Освобождение памяти более серьезная ошибка и более часто встречающаяся. А что там с изменение констаны, это оператор DATA? Замечательная логика - "не понял, о чем идет речь, но сишная все равно чаще". Нет, это не оператор DATA - тот работает вполне предсказуемо. Это следующий прикол: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Я константы всегда объявлял константы как parameter, вроде поменять нельзя, но возможно ошибаюсь. Но это поздние версии фортрана. softwarer c127GOTO неудобно, согласен, для выхода из цикла в поздних версиях фортрана был введен оператор типа break. Это утверждение выглядит странно, если сопоставить его с более ранним "я бы оставил в Си только FOR, убрав WHILE". Речь шла только о сишном for, он эквивалентен while, в фортране, паскале while нужен, там цикл его не заменяет. И что? BREAK эквивалентен GOTO; по той же самой логике он в фортране не нужен. Да и в остальных языках тоже. softwarer BREAK - это одна из форм оператора GOTO. Всей разницы - экономия нескольких символов на метке. Это ровно такая же приятная мелочь, синтаксическое удобство, как и сишный цикл while. GOTO запутывает оптимизатор, оптимизатор не знает куда будет переход. BREAK учесть легче, это частный случай GOTO. Насколько я готов утверждать без доставания книги по оптимизации - никакой разницы. В любом случае анализируется граф переходов. Та же история что и с циклами, чем более общий случай тем труднее его оптимизировать. Отнюдь не та же. У упомянутых циклов - разные возможности. break и goto - близнецы-братья. Если не ошибаюсь на момент создания фортрана структурного программирования не было и близко. Хм. Знаете, я пожалуй завершу этим письмом наше обсуждение. Вы зачем-то ведете в сторону "я защищаю язык, на который софтварер нападает". Когда концепция появилась фортран подрехтовали, теперь на нем легко можно программировать структурно без GOTO. Для этого потребовалось 3 оператора: switch, while, break. Не так много. Во-первых, прошу таки помнить, что "структурно" и "без GOTO" - абсолютно разные вещи. Не составляет ни малейшей проблемы написать классический спагетти-код без единого GOTO. Во-вторых, я так понимаю, что в каких-то из новых версий недостаточность управляющих конструкций таки исправили. Это, безусловно, хорошо, и это же доказывает, что она была. softwarer Еще раз: цикл с переменным шагом . Примерно так: Код: plaintext Вот и попробуйте соптимизировать такой цикл. Компилятор вообще не знает что там происходит. По этой причине вообще циклы не оптимизирует на всякий случай. Шучу конечно, но доля правды есть. Не уходите в сторону. "Доля правды" есть в том, что цикла DO не хватит для реализации такого цикла, соответственно его возможностей недостаточно для типичной, подчеркиваю, задачи численных вычислений. Другая доля правды - такой цикл тем не менее можно оптимизить, а вот его же реализацию через IF/GOTO - можно, наверное, но сомневаюсь, что писали столь развитую логику. А в фортране цикл определяется таким образом, что на момент входа в цикл программа знает сколько раз он будет выполняться. Единственный способ прервать - опрератор break, который в языке появился. А goto компилятор запутывает, его использовать в этой ситуации не рекомендуется. И для которого из циклов легче написать оптимизатор по-Вашему? На самом деле одинаково. Оптимизация цикла, если грубо, распадается на две группы: во-первых, преобразования, связанные со структурой цикла (например, вынесение константных операций), во-вторых, преобразования, связанные с вариантом цикла (раскрытие цикла, индуктивные переходы, изменение порядка обхода на нисходящий итп). Итого, разница только в выделении вариан(ов) цикла. Неустранимой причины конечно же нет, все работаем на одной и той же машине Поста, но вот технические есть. Как результат в книгах по фортрану (например в книге "Оптимизация в фортране", автора не помню, книги нет под рукой) советовалось не выносить повторяющиеся вычисления из цикла с целью оптимизации, поскольку компилятор их найдет и вынесет сам и сделает это лучше, а вот компиляторы по С вроде очень часто не выносят и вычисляют каждый раз. Хм. "Очень часто" зарождает подозрение, что идет сравнение с "обычным стиральным порошком", а хороший таки будет не хуже. Трудно говорить о книге, которую в глаза не видел, но абстрактно можно отметить следующий факт: вынесение повторяющихся вычислений - преобразование, которое абсолютно не зависит от структуры цикла. От структуры цикла зависят индуктивные преобразования, но как раз в этом месте для C очень старались сделать эффективную оптимизацию. softwarerНе очень вижу, за счет чего встроенный тип комплексных чисел будет оптимизиться сильно лучше, чем пользовательский, но и не решусь возражать. А что тут смотреть, в С типа complex нет. А в математических библиотеках для него - 100% есть. Точно так же, как и с файлами. А лучше за счет того что: 1) программа где complex нужен получается компактнее, C какой стати? Это еще можно было бы сказать об оригинальном, "системном" Си, но не о языке "прикладного периода". 2) библиотеки оптимизирует производитель компилятора а не я, Лучше, если оптимизирует производитель библиотеки. А производитель компилятора сосредотачивается на оптимизации компилятора :) с127Согласен, маркетинг штука страшная. Но во времена господства фортрана такой маркетинге никому не мог и присниться. Я бы сказал, это чистой воды везение :) К тому же так оказалось что С гораздо ближе к универсальному языку чем фортран, хоть и создавался совсем с другими целями. Мне он очень нравится. Если еще утечку памяти побороть, то вообще бы все было хорошо. Но как всякое универсальное средство С проигрывает специальным в их узких областях. с127 softwarerВашу мысль стоит представить в табличном виде. Есть Это была шутка, типа Ваша логика, доведенная до абсурда. А с какого бока это была "моя" логика? Мой оппонент пошел сравнивать по дико формальным признаком. Если не ошибаюсь, где-то у меня мелькнула фраза: "Вы еще скажите, что называются одинаково". И вдруг выясняется, что это моя логика.. softwarer И кстати - почему именно на Паскаль? В Си цикл тоже называется FOR. Потому что в С цикл for это нечто сложное, а у всех остальных - простое.[/quot] Цикл FOR в бейсике много сложнее, чем в Паскале - он позволяет произвольный шаг, позволяет работать с вещественными переменными...... И что же это в цикле у паскаля такое, что не умеет фортрановский цикл? Код: plaintext Опять речь о терминологии. Ладно, пусть нет подпрограмм, тогда это делает бейсик еще менее похожим на фортран. В этом случае "нет подпрограмм" - уникальная особенность "того" бейсика. Как, впрочем, и "нет формальных параметров" :) Да, это различие. У любого языка есть различия с любым другим, даже если они очень похожи. softwarer Цикл есть цикл, даже если он записывается как goto, от этого ничего не меняется. А если нет формальных параметров это все, их ничто не заменяет. Да бросьте. Точно так же заменяется. Это технически, а с точки зрения логики и понимания это существенная разница. Параметры это следующий после подпрограмм типа GOSUB шаг в абстрактном мышлении. Абсолютно те же слова можно сказать и про цикл. Но отмечу, что параметры - это не "следующий", а "тот же" шаг в мышлении. Альтернатива - сказать, что половину расстояния между концепциями "отрезка" и "треугольника" можно пройти, поставив на отрезок точку и назвав получившееся вырожденным треугольником. Не знаю как оно было изначально, но в фортране 77 уже можно было по-моему. По моим воспоминаниям, в Fortran IV номера файлов были "магическими числами". То есть в операторе ввода-вывода просто писалась константа и ничего другого сделать было нельзя. Почему я и выделил этот момент в сравнении с бейсиком, где по крайней мере в середине восьмидесятых еще было так же (сейчас, наверное, все же сделали нормально - не знаю). softwarer Хм. Возможно, я неправильно понимаю смысл "процедурного" языка. В том, на что Вы отвечаете, названы ALGOL, PL/I, Pascal, С. Кто из них менее процедурен, чем бейсик, и почему? Все одинаково процедурны. А вот ЛИСП и АПЛ (по-моему), которые Вы вспоминали, не процедурные. Я их вспоминал в другом контексте и по другому поводу. Но на момент придумывания бейсика (середина 60-х) 1) паскаля не было, Не было. 2) у алгола были проблемы с комрилятором, либо же компилятора не было вообще, точно не помню, Хм. Не очень понимаю, о каких проблемах идет речь. В силу некоторых особенностей языка компиляторы Алгола были очень сложны в сравнении с современниками - насколько я помню, среди прочего Дейкстра доказал, что для ALGOL-64 теоретически невозможно сделать менее чем четырехпроходный компилятор. Но тем не менее по практическому использованию, они с Фортраном - ровестники. 3) ПЛ/1 не знаю был ли, может тоже не было. Был. Появился несколько раньше бейсика. Чтоб не ходить по кругу в вопросе о бейсике как наследнике фортрана предлагаю определиться. Я считаю что чтобы язык программирования D назвать наследником языка F необходимо выполнение двух условий: 1) авторы языка должны в явном виде заявить что D создавался на основе F 2) в момент создания D должен быть нацелен на решение тех же задач что и F Хм. А Вы сможете назвать хотя бы одну пару из основных языков (не диалектов), для которых выполнятся оба этих условия? Соглашусь, в такой постановке вопроса говорить о наследовании практически бессмысленно. Вывести Perl из какого-нибудь другого шелловского языка наверное еще получится, но не более того. Собственно, в такой постановке вопроса окажется непросто даже вывести Delphi как наследник Turbo Pascal-я :) Поэтому бейсик НАСЛЕДНИКОМ фортрана назвать нельзя. Его можно назвать потомком, ответвлением, но не наследником. Браво! Замечательно. Теперь позволю себе процитировать то утверждение четырехстраничной давности, с которого все началось, на которое и пошли ваши возражения: softwarerФортран - предок бейсика, первый из проектов ряда "давайте программировать без программистов" И вдруг, после стольких сломанных копий, оказывается, что с этим Вы и не спорите - Фортран предок, бейсик - потомок. Не нравится же Вам слово "наследник", вылезшее уже в середине обсуждения (на четвертой странице). Если говорить о лишних и неудачных конструкциях в фортране, то они наверняка есть. Но все познается в сравнении, если посмотреть на другие языки, то там их как правило несравнимо больше, если фортран тут как-то выделяется, то только в лучшую сторону по-моему. И снова начинается флейм на тему "лучше-хуже". Нет, я таки завершаю эту беседу, тем более что как вдруг оказалось, Вы соглашаетесь с тем, о чем мы вроде бы начали спорить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 12:21 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
tchingizВаше утверждение было безусловным "отовсюду", а в примере условие. "Отовсюду в рамках того, что умеет язык". Этак и для бейсика можно сказать, что не отовсюду - можно подключить к бейсик-программе внешнюю подпрограмму на другом языке, но вот достучаться из той до бейсиковских переменных будет непросто. tchingiz2 и даже в Вашем примере. если разместить глобальную переменную внизу файла, чтото мне подсказывает, что ее не будет видно "ниоткуда" Будьте аккуратнее. Я сказал "бейсиковским образом". В бейсике в этом случае ее тоже не будет "видно неоткуда", только порядок идет не по сортировке строк, а по порядку их выполнения. Опять же, особенности языка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 13:10 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкудля меня "интерпретатор" значит следующее: исходник где строка 1- синтаксически правильна, а вторая - нет частично работает Хм. Признаться, не готов разделить такое определение - все же я бы сказал, критерием является наличие собственной среды исполнения, "исполняемый код уровня выше машинного". Как косвенный признак - наличие функции eval(), возможность на ходу отпарсить и выполнить какой-то переданный код. В противном случае из интерпретаторов пришлось бы исключить, например LISP. Ну и кучу того, что обычно таковыми называется - PL/SQL, например. fff выводится а дальше -ошибка. С другой стороны, сказанное - практически ничего не говорит. Согласитесь, нет проблемы написать компилятор, который будет удовлетворять этому критерию :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 13:47 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarerС другой стороны, сказанное - практически ничего не говорит. Согласитесь, нет проблемы написать компилятор, который будет удовлетворять этому критерию :) Вообще да. Но это народный способ :-). И никак не определение. Конечно он прокалывается - например Visual Basic так себы ведет, хотя он вроде уже нифига не интерпретатор. Кстати, наличие функции eval() - ни о чем не говорит. Она есть в том же perl, python etc. Это просто встроенный интерпретатор, ну его можно встроить и в сишную программу и в какую угодно - думаю Вы прекрасно об этом осведомлены :-) А PL/SQL кстати интерпретатор? Я Oracl не знаю, но в MS SQL/Sybase говорят "я перекомпилировал процедуру", "преимущество процедур в скорости - в том, что они на сервере прекомпилированные". У Саукапа написано, как происходит работа с процедурами Transact SQL, там вроде как действительно интерпретируются они а потом уже компиленные. Наверное PL/SQL так же? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 16:33 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
В 9-ке появилась возможность компиляции PL/SQL в native код ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 16:54 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуКстати, наличие функции eval() - ни о чем не говорит. Она есть в том же perl, python etc. А с каких пор они перестали быть интерпретаторами? :) Хотя про python не уверен - мало знаю. лыко в строкуЭто просто встроенный интерпретатор, Да. При этом, если доступен тот же самый язык, что и "снаружи" - обычно это тот же самый интерпретатор и есть :) лыко в строкуну его можно встроить и в сишную программу и в какую угодно - думаю Вы прекрасно об этом осведомлены :-) Безусловно, можно. Но "встроенные" интепретаторы обычно принципиально менее функциональны. Сишная программа, в которую встроен полный интерпретатор Си, к тому же способный взаимодействовать с внешней программой - мягко говоря, нечастое извращение :) Впрочем, как я сказал, это именно косвенный признак. лыко в строкуА PL/SQL кстати интерпретатор? Я Oracl не знаю, но в MS SQL/Sybase говорят "я перекомпилировал процедуру", "преимущество процедур в скорости - в том, что они на сервере прекомпилированные". Интерпретируется промежуточный код. Точнее, есть два варианта: более старый - такой вот интерпретатор, более новый - компиляция в выполняемый код. лыко в строкуУ Саукапа написано, как происходит работа с процедурами Transact SQL, там вроде как действительно интерпретируются они а потом уже компиленные. Наверное PL/SQL так же? Боюсь, не понял фразы и не знаю автора. Насколько я в курсе, в T-SQL схема примерно та же с той разницей, что при компиляции строятся планы запросов, а в оракле это делается при выполнении процедуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 17:37 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarerХотя про python не уверен - мало знаю. Псевдокомпилятор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 17:53 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
разумеется я вел речь не о компиляторах в машкод, а о компиляторах в p-код, байт-код или как там его называют. О них именно говорил господин Gluk (Kazan). (псевдокомпиляторы, генераторы байт-кода или что-то в этом роде.) perl как известно сначала делает бинарный код (машинный), а потом его исполняет. Только этого кода никогда никто не видел ибо в памяти он. Так что он совсем не интерпретатор. А вот python - вполне можно все кроме головного модуля компилить в *.pyc метод compiler.compileFile и другие. Такой же принцип создания байт-кода, что и в java. Да и .NET это тот же путь. Компилятор C# - это компилятор? :-) На самом деле и с tcl я немного слукавил - в какой-то новейшей версии (9?) и его хотели перевести на byte-code, но получилось ли у них что-то неизвестно. У него как-то развитие притормозилось к счастью. И Perl 6 говорят таким будет [испортят хорошую вещь (c) :-(] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 19:06 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуperl как известно сначала делает бинарный код (машинный), а потом его исполняет. Только этого кода никогда никто не видел ибо в памяти он. Так что он совсем не интерпретатор. Этот вариант я бы как раз назвал чистым интерпретатором. То, во что он преобразует глубоко внутри себя - его внутреннее же дело. Черный ящик, на входе которого - исходный текст, на выходе - выполняющаяся программа. Можно сказать, что это "интерпретатор, содержащий встроенный компилятор". Что, впрочем, за исключением генератора исполняемого кода есть абсолютно стандартный вариант. Также можно сказать, что по "требованиям к языку", ограничениям, легкости реализации каких-то фич этот продукт должен быть ближе именно к "стопроцентным компиляторам". лыко в строкуТакой же принцип создания байт-кода, что и в java. Да и .NET это тот же путь. Компилятор C# - это компилятор? :-) Если говорить о java, то это интерпретирующая среда исполнения (которая собственно называется java) в сочетании с выделенным в отдельный инструмент компилятором в байт-код (который называется javac). В принципе о такой конструкции можно говорить как о гибриде. С моей точки зрения, о "java в целом" правильнее говорить как об интерпретаторе потому, что байт-код вообще говоря произволен; так, даже самые интерпретирующие интерпретаторы не парсят каждый раз строку (если не говорить об... экстремальных поделках), но переводят ее во внутреннее представление (пусть и эквивалентное исходному - просто короткая запись). Соглашусь, что на определенном уровне обсуждения стоит выделить подобные гибриды в отдельный класс. Правда, тогда опустеет класс "собственно интерпретаторов", и соответственно утверждение, с которого все пошло - "все интерпретаторы позволяют не объявлять переменные" - теряет смысл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 19:32 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
в принципе "гибриды" ближе к компиляторам- просто они генерят код не для реальных процессоров, а для софтверных (виртуальных). Которые к тому же имеют шанс воплотиться и в железе (вроде для Java делали). Про perl не соглашусь - он именно компилирует , просто для пользователя это выглядт как интерпретация в том плане что он глотает сорц и сразу отрабатывает. Процесс компиляции у него скрыт "под капотом". Вы же не назвали бы компилятором такую систему: Код: plaintext у нее такое же поведение, как у perl - мы создаем исходник, запускаем и получаем результат работы. Просто она промежуточный бинарный код хранит в виде файла. Ну и синтаксис другой - но это ведь детали :-) IMHO истинный интерпретатор - тот, который берет строчку кода, исполняет и переходит к следующей и так далее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 19:44 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Вы же не назвали бы компилятором такую систему заменить на Вы же не назвали бы интерпретатором такую систему ----- лыко в строку уже лыка не вяжет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 19:57 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Можно и процессор считать интерпретатором нативного кода. В таком ракурсе, разговоры о преимуществах нативного кода - чистой воды гегемония. По поводу байт-кода. Ну... он возник задолго до Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 20:06 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
авторПо поводу байт-кода. Ну... он возник задолго до Java. никто не спорит :-) Думается, все же интерпретация - построчный разбор и выполнение кода языка высокого уровня, можем отталкиваться от этого? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 20:09 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку Думается, все же интерпретация - построчный разбор и выполнение кода языка высокого уровня, можем отталкиваться от этого? Во всех ли языках можно выделить строки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 20:12 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Согласен, давайте закругляться, спор уже давно стал неконструктивным. Пара замечаний. Абсолютно всякий язык высокого уровня создавался именно для того чтоб могла программировать домохозяйка, т.е. по Вашей классификации человек, не знающий конкретной архитектуры машины ("давайте программировать без программистов"). В этом смысле пара бейсик - фортран абсолютно ничем существенным не выделяется. softwarer Поэтому бейсик НАСЛЕДНИКОМ фортрана назвать нельзя. Его можно назвать потомком, ответвлением, но не наследником. Браво! Замечательно. Теперь позволю себе процитировать то утверждение четырехстраничной давности, с которого все началось, на которое и пошли ваши возражения: Ну Вы же сами заговорили о наследнике ( Я не очень понимаю Вашей точки зрения "раз наследник - значит, должен быть шире" 6 сен 05, 11:19 [1849310]). Но тут я тоже неточно выразился, следует читать: " в лучшем случае его можно назвать потомком, ответвлением, но не наследником." Т.е. я хотел сказать, что серьезных аргументов против того, чтоб считать бейсик потомком фортрана у меня нет, абсолютно всякий язык Б, появившийся после языка А можно считать потомком А, но в случае с бейсиком и фортраном мне это кажется натяжкой. Против наследника у меня естественно тоже нет строгих аргументов, все действительно сводится к вопросу классификации. Свое нестрогое определение наследника я представил. Пример удовлетворяющей ему пары: С++ наследник С. Я в принципе согласен, что можно классифицировать достоинства-недостатки обсуждаемых языков так как это делатете Вы, мне это кажется неестественным, но не ошибочным. Со следующими исключениями, которые я считаю ошибочными, но это всего лишь мое субъективное мнение. *) в С утечка памяти НА ПРАКТИКЕ есть очень большая проблема и решения в языке нет. В С нет динамически выделяемой памяти, которую бы освобождал компилятор, а программист это делать часто забывает. Вы может и не забываете, а я иногда забываю. Теоретически проблемы нет, а на практике есть. Ничего сравнимого по масштабам в фортране ИМХО нет. Это не значит что С плохой. Но к первоначальному вопросу это отношения не имеет. *) утверждать что тип complex в С так же просто использовать как в фортране есть ошибка. Это по-моему очевидно и я думаю, что Вы и сами не верите в то что говорите и возражаете просто из упрямства. Это тоже не имеет отношения к первоначальому вопросу. *) важность формальных параметров в функциях и подпрограммах подчеркивается по-моему всеми главными теоретиками программирования, нверное вообще нет ни одного кто бы не высказался по этому поводу аналогичным образом. Введение формальных параметров было большим шагом, поскольку сильно облегчило жизнь программистам. Поэтому наличие - отсутствие формальных параметров ИМХО является очень существенным. Но поскольку, как Вы верно заметили, речь идет не чем-то строгом, а о важно-не важно, легко-не легко, то конечно считать формальные параметры неважными никто не запрещает, все знают что можно обойтись и без них. Такая точка зрения противоречит общепринятому мнению, но общепринятое мнение штука ненадежная. Это имеет отношение к первоначальному вопросу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 21:46 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
maytonВо всех ли языках можно выделить строки? Настандартно :-) Допускаю, что не во всех. Но наверное для других существует какая-то своя единица интерпретации... mayton - но может назовете язык,в котором нельзя выделить строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2005, 22:54 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Да собственно во всех языках выделяются не строки, а операторы (statements). Просто в некоторых языках оператор должен укладываться в одну строку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2005, 11:12 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкув принципе "гибриды" ближе к компиляторам- просто они генерят код не для реальных процессоров, а для софтверных (виртуальных). Которые к тому же имеют шанс воплотиться и в железе (вроде для Java делали). Да и для LISPа делали. Как минимум, пытались - не помню, насколько преуспели. Не соглашусь. Если грубо, любой интерпретатор состоит из "компилятора" и "интерпретирующей платформы", и в этом смысле все одинаково близки к "полностью компиляторам". Собственно, в рамках такого разговора я бы предложил считать, что "интерпретатор" состоит из "компилятора и интерпретирующей плаформы", а "компилятор" - из "компилятора и генератора низкоуровневого кода". Байт-код java вполне успешно декомпилируется обратно в исходники. Это означает, что данный конкретный компилятор (javac) достаточно тривиален, а вот байт-код - отнюдь не низкоуровневый. Соответственно, имхо этот продукт - ближе к интерпретаторам. Вы же не назвали бы компилятором такую систему: Код: plaintext Не назвал бы. Но - подозреваю - есть одно различие, которое будет для меня ключевым: неотделяемость. Подчеркну, это именно подозрение - но по Вашему рассказу у меня сложилась гипотеза, что генерируемый перлом "исполняемый файл" - это просто серия вызовов подпрограмм, предоставляемых "ядром". По такой технологии также были построены некоторые "интерпретаторы" или, если угодно, "полукомпиляторы" - например, Clipper. IMHO истинный интерпретатор - тот, который берет строчку кода, исполняет и переходит к следующей и так далее. Таких по большому счету не существует уже лет тридцать. Согласен, можно считать его "истинным" - хотя различие тут на самом деле косметическое, поскольку он состоит все из того же "компилятора" и "интерпретирующей платформы", просто "компилятор" чаще вызывается, а результаты его работы особенно быстро забываются. Сами понимаете, такая схема помимо прочего неудобна для языков, в которых присутствует хоть какая-то структура программы. Для бейсика она реализуется легко - а вот для явы будет чрезвычайно неудобна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2005, 17:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
c127Абсолютно всякий язык высокого уровня создавался именно для того чтоб могла программировать домохозяйка, т.е. по Вашей классификации человек, не знающий конкретной архитектуры машины ("давайте программировать без программистов"). Простите, но это не моя классификация. "Домохозяйка - человек, не знающий конкретной архитектуры", или "программист - человек, знающий конкретную архитектуру" - таких утверждений у меня нет и не было. Существует как минимум один ЯВУ, создававшийся "не для домохозяек" - Си. Один - потому что лень подбирать другие примеры :) c127В этом смысле пара бейсик - фортран абсолютно ничем существенным не выделяется. Выделяется именно ориентацией на предметников. Фортран так был задуман (если не ошибаюсь, Вы сами говорили об этом), у Бейсика под этим лозунгом прошло "второе рождение" (в семидесятые годы, когда появились мини-ЭВМ и обнаружилось желание решать кучу "мелких" задач при дефиците программистов). c127Ну Вы же сами заговорили о наследнике Я употребил неудачный синоним. И вместо того, чтобы сказать об этом и быстро решить вопрос - получилось так, что Вы спорили с этим синонимом, в то время как (по крайней мере мне) казалось, что Вы спорите с исходной мыслью. Свое нестрогое определение наследника я представил. Пример удовлетворяющей ему пары: С++ наследник С. Не согласен. Не удовлетворяет эта пара Вашему определению. Я в принципе согласен, что можно классифицировать достоинства-недостатки обсуждаемых языков так как это делатете Вы, мне это кажется неестественным, но не ошибочным. Со следующими исключениями, которые я считаю ошибочными, но это всего лишь мое субъективное мнение. *) в С утечка памяти НА ПРАКТИКЕ есть очень большая проблема и решения в языке нет. Как человек, поработавший и с явным выделением-освобождением памяти, и со сборкой мусора, я предпочитаю первый подход - соответственно, не считаю его большой проблемой. Но если Вы обратите внимание - я говорил, что эта проблема решена к настоящему моменту, имея в виду C++ Это не значит что С плохой. Но к первоначальному вопросу это отношения не имеет. Безусловно. А какой собственно начальный вопрос Вы имеете в виду? *) утверждать что тип complex в С так же просто использовать как в фортране есть ошибка. Это по-моему очевидно и я думаю, что Вы и сами не верите в то что говорите и возражаете просто из упрямства. Это тоже не имеет отношения к первоначальому вопросу. Стоп. Давайте уточним. Не помню уже кто именно, формулируя утверждение про прикладное программирование на Си, говорил о настоящем времени, то есть о С++. Чем там использовать тип complex сложно по сравнению с фортраном - не понимаю; если хотите, считайте это упрямством. Если говорить о чистом Си, безусловно, придется заменить использование операций +-*/ на вызов функций. Несмертельно, но неудобно. *) важность формальных параметров в функциях и подпрограммах подчеркивается по-моему всеми главными теоретиками программирования, В противопоставлении подпрограммам без параметров? Можно конкретные цитаты? нверное вообще нет ни одного кто бы не высказался по этому поводу аналогичным образом. Введение формальных параметров было большим шагом, поскольку сильно облегчило жизнь программистам. Поэтому наличие - отсутствие формальных параметров ИМХО является очень существенным. Но поскольку, как Вы верно заметили, речь идет не чем-то строгом, а о важно-не важно, легко-не легко, то конечно считать формальные параметры неважными никто не запрещает, все знают что можно обойтись и без них. Такая точка зрения противоречит общепринятому мнению, но общепринятое мнение штука ненадежная. Это имеет отношение к первоначальному вопросу. Итак, Вы перевернули мою мысль. Я говорю, что "введение подпрограмм" и "введение формальных параметров" - один и тот же шаг. Вы отвечаете - "можно считать параметры неважными". Извините, но я прекращаю всякую беседу с Вами. Ответа на заданные ранее вопросы не жду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2005, 17:50 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer c127 Свое нестрогое определение наследника я представил. Пример удовлетворяющей ему пары: С++ наследник С. Не согласен. Не удовлетворяет эта пара Вашему определению. .... Но если Вы обратите внимание - я говорил, что эта проблема решена к настоящему моменту, имея в виду C++ ... формулируя утверждение про прикладное программирование на Си, говорил о настоящем времени, то есть о С++ Ну и? Страуструп говорил что при создании ориентировался на С (пункт 1 моего определени), Вы сами используете С/C++ практически как синонимы (пункт 2 моего определения), но при этом моему определению наследника не удовлетворяет. softwarer Но если Вы обратите внимание - я формулируя утверждение про прикладное программирование на Си, говорил о настоящем времени, то есть о С++ " Для начала стоит отличить Си и Cи++ ". (softwarer 3 сен 05, 17:30 [1843630]) Будьте последовательны, если различать то уж различать. После справедливого замечания Gluk (Kazan) ([1844091]) Я так и старался подходить к этому вопросу, откуда же мне знать что оппонент уже поменял точку зрения. softwarer А какой собственно начальный вопрос Вы имеете в виду? ... Стоп. Давайте уточним. ... Можно конкретные цитаты? ........... Извините, но я прекращаю всякую беседу с Вами. Что это было? Закругляемся или нет? По-моему пора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2005, 22:16 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer с127нверное вообще нет ни одного кто бы не высказался по этому поводу аналогичным образом. Введение формальных параметров было большим шагом, поскольку сильно облегчило жизнь программистам. Поэтому наличие - отсутствие формальных параметров ИМХО является очень существенным . Но поскольку, как Вы верно заметили, речь идет не чем-то строгом, а о важно-не важно, легко-не легко, то конечно считать формальные параметры неважными никто не запрещает, все знают что можно обойтись и без них. Такая точка зрения противоречит общепринятому мнению, но общепринятое мнение штука ненадежная. Это имеет отношение к первоначальному вопросу. Итак, Вы перевернули мою мысль. Я говорю, что "введение подпрограмм" и "введение формальных параметров" - один и тот же шаг. Вы отвечаете - "можно считать параметры неважными". гы. кто отвечает, что формальные параметры можно считать не важными? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2005, 05:09 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
--null-- c127, просвети пожалуйста - чем же еще таким занимается БГ, отдавая ентому занятию все больше времени в ущерб Майкрософт? Может, тайно учайствует в разработке того же Linux али же на кухне Sinclair-ы паяет по ночам? :-) это не бг, но всеже ------------------------------- г-н Баллмер поднял стул, швырнул его через всю комнату, и попал в стол. После этого глава крупнейшей корпорации разразился негодующей тирадой по поводу исполнительного директора Google Эрика Шмидта (Eric Schmidt) и его компании: «Я собираюсь похоронить к чертям этого парня, мне не впервой, сделаю еще раз. Я собираюсь убить к чертям этот Google.» Ранее Эрик Шмидт работал на Sun и был главой Novell. ----------------- http://www.cnews.ru/news/top/index.shtml?2005/09/07/186186 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2005, 10:00 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarerДа и для LISPа делали. Как минимум, пытались - не помню, насколько преуспели. Преуспели видимо, были же такие LISP-компьютеры. Насчет обратимой компиляции... Думаю, то, что java байт-код можно с определенной точностью вернуть к исходнику (ну потеряются конечно имена) - это частный случай. Наверное все зависит от пресловутой архитектуры ( то же самое на "железной" java машине можно сделать - но это-то уже точно компиляция или те же самые Lisp machine). Хотя я совсем не знаток теории компиляторов, так что может и неправ. softwarerНо - подозреваю - есть одно различие, которое будет для меня ключевым: неотделяемость. ... Подчеркну, это именно подозрение - но по Вашему рассказу у меня сложилась гипотеза, что генерируемый перлом "исполняемый файл" - это просто серия вызовов подпрограмм, предоставляемых "ядром". Хм, скажем - perlcc, вроде он и есть это самое недостающее звено эволюции -переводит все это в сишный код. "perlcc - frontend for perl compiler " в данном случае perl выступает как компилятор. Вспомните, что раньше (а может и сейчас) c-шный компилятор в unix не генерил машкод, а делал ассемблерные исходники. А perl... да поправят меня знатоки - он все-таки создает на лету _бинарный код_ - именно для той модели процессора, на которой исполняется, а не для какого-то там рантайма или виртуальной машины. Поэтому он все же близок к компиляторам. Может, Clipper так и работал, вряд ли Ларри Уолл - первооткрыватель в этой области. И еще softwarerТаких по большому счету не существует уже лет тридцать Это не совсем так - может они не _создаются_ лет *дцать - примерно столько же впрочем, сколько не создается новых общеупотребимых компилируемых языков. А чистые интерпретаторы (те же языки оболочек) - до сих пор живут и используются и конца этому не предвидится. Все последние достижения - perl,python,java, C# и компания , Ruby и что там еще я забыл :-) - все это "гибриды", мы живем в век гибридов , а динозавры - вытесняются, уходят в узкоспециализированные ниши (компиляторы - в "системщину", интерпретаторы - в обеспечение оболочек, командных языков) Все вообще настолько перемешано,что я даже не совсем спорю, так как с большинством Ваших утверждений нельзя не согласиться, просто может в результате лучше пойму терминологию. А по топику - "Delphi - универсальнейший инструмент разработки" - насчет разработки не известно, но как инструмент для раздувания религиозно-философских диспутов - наиуниверсальнейший. Проверено - и не только здесь :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.09.2005, 19:53 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуНасчет обратимой компиляции... Думаю, то, что java байт-код можно с определенной точностью вернуть к исходнику (ну потеряются конечно имена) - это частный случай. Это просто показывает, что код - высокоуровневый, ничего более. Скажем, поскольку в восстановленном исходнике сохраняются разные виды циклов - есть основания предполагать, что в байт-коде им соответствуют разные операции. То есть бОльшая часть пути от исходника к выполняющейся программе проходится интерпретатором. лыко в строку Наверное все зависит от пресловутой архитектуры ( то же самое на "железной" java машине можно сделать - но это-то уже точно компиляция или те же самые Lisp machine). Безусловно, "внутренний компилятор" - часть интерпретатора. Но если говорить об интерпретирующих машинах - оставаться в формальных рамках будет запутывающей условностью; в железе в принципе можно реализовать и компилятор, машина будет выполнять программу в исходниках - а по сути ничего не меняется. лыко в строкуХм, скажем - perlcc, вроде он и есть это самое недостающее звено эволюции -переводит все это в сишный код. А можно небольшой пример сгенерированного таким образом кода? лыко в строку "perlcc - frontend for perl compiler " в данном случае perl выступает как компилятор. Вспомните, что раньше (а может и сейчас) c-шный компилятор в unix не генерил машкод, а делал ассемблерные исходники. И тем не менее он был компилятором. По той причине, что преобразование ассемблерных исходников в машинный код - тривиальная операция. И по той же причине "тривиальное преобразование явовских исходников в байт-код" является компиляцией довольно условно. "Тривиальное" здесь естественно в кавычках - поскольку проверить условия корректности довольно нетривиально. лыко в строкуА perl... да поправят меня знатоки - он все-таки создает на лету _бинарный код_ - именно для той модели процессора, на которой исполняется, а не для какого-то там рантайма или виртуальной машины. Поэтому он все же близок к компиляторам. Я понимаю. В лучшем случае можно сказать, что он содержит полноценный генератор кода и соответственно является еще более интересным гибридом. В худшем случае - генерируемый им код будет абсолютно тривиален. А чистые интерпретаторы (те же языки оболочек) - до сих пор живут и используются и конца этому не предвидится. Поэтому я и сказал "по большому счету". Языки оболочек - это все же игрушка, безусловно полезная и правильная, но не более того. У меня в одной из программ тоже действует чистый интерпретатор :) лыко в строкуА по топику - "Delphi - универсальнейший инструмент разработки" - насчет разработки не известно, но как инструмент для раздувания религиозно-философских диспутов - наиуниверсальнейший. Проверено - и не только здесь :-) В данном топике - раздул с незаурядной точки зрения. Обычно приходили брызгать слюной, а тут - завидуют. Мелочь, а приятно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 05:20 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку ... По поводу Perl. По моим личным наблюдениям, заслуги господина Ларри Уолла несколько преувеличены. Чисто из собственной лени человек создал язык-парадигму, где ВСЁ есть (только чёрта в ступе не хватает). Да вот вопрос в том, нужно ли ЭТО ВСЁ . Мои коллеги, давно используют Perl, однако по их признаниям - только для простых скриптиков и веб публикаций. softwarer ... Да. Я хотел упомянуть про Лисп . Но вы меня опередили. Язык слишком чист и рафинирован - а потому ИМХО практически применяется мало. Его можно ставить на полку в музей академических языковых разработок. По поводу языков для домохозяек. Ну.. есть точка зрения, что разработчик будет в скором времени не нужен. Не согласен с этим. Считаю, что работа программиста-разработчика качественно изменится в ближайшие 5-10 лет. От кодирования специалисты будут отказыватся в пользу проектирования . Благодаря кросс-переносимым библиотекам кода мы получим доступ к огромной базе (метабазе) свободно-распрпостраняемого кода на все случаи жизни . Проблемой лишь будет поиск подходящей компоненты (класса, интерфейса). Получат распространение языки искусственного интеллекта и программирования нейросетей, на которые вас покорный слуга давно смотрит с завистью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 10:27 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
maytonЧисто из собственной лени человек создал язык-парадигму, где ВСЁ есть (только чёрта в ступе не хватает). Да вот вопрос в том, нужно ли ЭТО ВСЁ . Для меня лично Perl обладает одним большим достоинством (хотя я его не использую, и не хотел бы использовать). Его реализация ООП - замечательный пример для вправления мозгов юношам, свежепрочитавшим книги по этому супермощносовременноуникальному подходу и со всем пылом новообращенных считающих его чем-то ниспосланным на скрижалях. Когда удается объяснить человеку, что "поддержка ООП в C++" - это всего лишь удобный синтаксис записи некоторых простых мыслей, с человеком становится резко проще иметь дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 16:48 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
просто в ООП там (в perl) "дно видно", так сказать :-) а "это все" - про любой язык так можно сказать. Ну не используете все возможности одновременно и не надо, так не бывает все равно. Сделано лаконично и прикольно. Во всяком случае многие его используют и вполне довольны. Для обработки текстов это лучший инструмент , что признано многими. P.S. про perlcc все-таки я не очень удачно пример привел - там генерируется монстр не содержащий напрямую код приложения, в промежуточном c файле появляется PerlInterpreter, так что видимо где-то чертова интерпретация все же задействована, но на выходе появляется полноценный бинарник. Наверное, perlcc и есть истинный компилятор perl :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 17:49 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку а "это все" - про любой язык так можно сказать. Ну не используете все возможности одновременно и не надо, так не бывает все равно. Сделано лаконично и прикольно. Во всяком случае многие его используют и вполне довольны. Для обработки текстов это лучший инструмент , что признано многими. Согласен, что сделано лаконично и прикольно, однако Perl неизбежно проигрывает по степени интеграции пользовательских библиотек. Я не замечал, чтобы повторное использование кода (как в нормальных языках) было правилом для Perl. Зачастую разработчик предпочитает выбросить слишком сложную библиотеку своего коллеги и по быстренькому сляпать свою, нежели разобратся в ней и поддержать. А это есть - нехорошо. P.S. Разве-ж Нимфа кисть дает? Туды яё в качель.... (с) Безинчук ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 18:35 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
2mayton ну да :-( Но только это наверное такой стиль исторически сложился. Возможно - из-за того, что много библиотек в стандарте и в инете, сам язык богат и относительно просто что-либо "сляпать" (как известно, свое часто делать быстрее и проще, чем в чужом разбираться) Попробовали бы они так в C - много клавиатур бы истерли пальцами - очень большой объем кода пришлось бы писать, все-из-за относительной бедности базовых библиотек, отсутствия в языке поддержки распространенных структур (хеши, списки, строки и т.д.) Получается, что perl просто стимулирует такой стиль. Говорят, что у него синтаксис "мусорный" - так это как писать. "Тайнопись" можно на любом языке развести, просто perl опять же для этого предоставляет слишком много средств. И потом есть другой пример - библиотеки CPAN на все(многие) случаи жизни. Их же используют и все довольны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 18:52 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкупросто в ООП там (в perl) "дно видно", так сказать Именно что. ООП лишается магического ореола, люди начинают думать "а что у него внутри". К сожалению, сейчас получается так, что "программисты", очень отрывочно представляя себе историю программирования, оказываются в положении людей, изучающих алгебру без знания арифметики. Упускаются мысли, которые когда-то были самоочевидными и потому мало где явно записаны :) И если при этом не очень склонны "копаться" - приходят к восприятию "черного ящика", "магии"; не понимают как работает, но знают, что если правильно выполнить определенный ритуал то обычно работает. А если не срабатывает - надо пошаманить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 21:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Давно в топике этом не появлялся. Поработал я щас с Делфёй седьмой. Вы знаете, она действительно универсальна. Огромное количество классов под рукой. Я за 3! (реально абсолютно) создал АктивХ, который позволяет редактировать вордовские файлы в осле (IE). Компоненьтик кастрированный пока. Но мне важно было понять техническую возможность. В Делфе есть инструменты на все случаи жизни. Среди трёх моих любимых IDE яб распределил первые места так: * KDevelop - удобство. Ничего удобней не видел. Это верх. Интегрируется со всем и вся. Великолепная подсветка синтаксиса. Бары (или табы. Ну эти в верху как в Опере.), единый файл на проект, в котором все настройки. Сказка. * Qt Designer - простота создания GUI Тож кликанье мышкой. Но что-то в нём такое, что делает его удобней Дельфи в этом плане. КуТэ Десигнер конечно не полноценная IDE. Но всёж. Отдельно отмечю справочную стстему Qt. Неотемлемая часть любой IDE. Лучшая, пожалуй, F1. * Delphi - универсальность. Достаточна удобна. Но до КДевелопа не дотягивает. Удобный редактор интерфейса (но не дотягивает до кутэ десигнера). Справочная система почти так же хороша, как и в КуТэ. Но конёк Дельфи - универсальность. ------------ Всё вышесказанное - имхо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 22:36 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarer И если при этом не очень склонны "копаться" - приходят к восприятию "черного ящика", "магии"; не понимают как работает, но знают, что если правильно выполнить определенный ритуал то обычно работает. А если не срабатывает - надо пошаманить Как я понимаю, в умных книжках именно это и называется "разработчик, находящийся на определенном уровне абстракции". К этому долго и упорно шла индустрия IT все последние годы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2005, 23:56 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
кто долго и упорно шел, а кто от уровней абстракции и не отходил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 00:31 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
автор Код: plaintext 1. 2. 3. Ну и грамотеи тут собрались! Вспомнили бы еще бэйсик калькулятора. Вообще-то автор задал вопрос... Кончено же Delphi для русского - как религия. Вся Америка выросла в джинсах, вся Россия - в паскале. Вот и весь секрет популярности. Читал когда-то историю проекта Delphi. Для Борланд сначала было неочевидно какой язык выбрать за основу проекта. Выбор пал на паскаль только потому, что в нем стандарт был всего 43 страницы (против 1000 страниц стандарта С++). Борланду надо было иметь большую свободу в доработке языка (ну и перспективы дел судебных за несоблюдение стандарта то же имели место). По-моему любой язык в обойме Delphi обречен был на успех. Ведь успех делфы не в языке, а в полноте среды разработки. В противоположность практике плодирования библиотек, зачастую несовместимых, и от noname-производителей. Почему М$ смогла так раскрутить джаву? Да так что теперь вот сама с ней воюет не ее-же поле :). Наверно то же самое - наконец-то в 96 программисты получили пакет джавы, где все в одном флаконе (и отнюдь не сомнительного качества!). Что мы видим в последние годы? Большинство дельфинистов программируют на старых версиях дельфи. Вовсю используются сторонние библиотеки (не Борландовские!). BDE. Каким он был - таким остался. Так ничего борман не смог противопоставить ADO (не путать борландовскую отсебятину, почему-то названную ADO, с настоящей ADO!). А основной доход Борланда уже давно (лет 5) составляет отнюдь не дельфи - Джава. Но и этот кусок вырван изо рта Борланд. IBM постаралась. В последние годы они переключились на новую нишу: поддержка совмещения разных технологий. И кажется эта ниша долго будет для них прибыльной. Значит ли это что они прекратят поддержку дельфи? А что ее поддерживать-то? Написали паскаль для дотнет – вот и поддержка. Даже название оставили старое – Дельфи. А если говорить о разных языках... Сегодня актуально применение ООП. А здесь несмотря на различия самих языков, почти во ВСЕХ языках используется модель ООП разработанная Страуструппом. И ObjectPascal - то же "натянут" за уши на этот стандарт. Обособленно стоит только "Оберон". Но борланд не хотела следовать взглядам Вирта. Она прогнулась под плюсы. Еще до дельфи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 09:10 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку softwarer И если при этом не очень склонны "копаться" - приходят к восприятию "черного ящика", "магии"; не понимают как работает, но знают, что если правильно выполнить определенный ритуал то обычно работает. А если не срабатывает - надо пошаманить Как я понимаю, в умных книжках именно это и называется "разработчик, находящийся на определенном уровне абстракции". К этому долго и упорно шла индустрия IT все последние годы. Если точнее, она идет к этому добрых сорок последних лет и будет идти еще сорок тысячелетий, если проживет так долго. В терминах нашей беседы "Разработчик, находящийся на определенном уровне абстракции" == "домохозяйка". Моя точка зрения по этому поводу очень точно изложена здесь: http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 11:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
WorobjoffПо-моему любой язык в обойме Delphi обречен был на успех. "Успех" C++Builder и JBuilder убедительно доказывает Вашу точку зрения. Worobjoff Ведь успех делфы не в языке, а в полноте среды разработки. В противоположность практике плодирования библиотек, зачастую несовместимых, и от noname-производителей. Отнюдь. Хотя бы потому, что основная мощь дельфы - именно в библиотеках, зачастую несовместимых, от более или менее noname-производителей. Причина успеха дельфы в том, что смогли создать идеологию, язык и инструменты, которые очень хорошо сочетаются друг с другом. Когда в ту же канву попытались засунуть C++ - который туда просто не подходит - получили уродца, которого "настоящие программисты на C++" не считают собственно C++ (и с моей точки зрения, правильно делают). WorobjoffА здесь несмотря на различия самих языков, почти во ВСЕХ языках используется модель ООП разработанная Страуструппом. Сильно сказано. Я бы сказал, очень сильно. И в чем же отличия этой модели от других моделей ООП - те отличия, на основании которых Вы так относите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 11:52 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html Интересно, что историю развития C++ можно описать как историю затыкания дырок в абстракции строк. Уж не знаю, отчего бы не добавить к языку элементарный класс строчек. Хе-хе... солидарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 12:45 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
почитал http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html Забавно. Правда немного спекулируют насчет тех же протоколов: нигде не написано, что "надежность" TCP гарантируется абсолютно. Имеется в виду гарантия доставки - т.е. что отправитель будет всегда уведомлен об успешной доставке данных получателю или уведомлен об ошибке (уже одно это отрицает абсолютность). Кроме того - имеется в виду только обеспечение транспортного уровня - когда хомяк перегрызает провод - это уже физический :-) "будто TCP гарантирует, что сообщение прибудет на место." - ерунда, об этом нигде не могло быть написано, он гарантирует лишь что если оно придет, то мы об этом узнаем и гарантирует то, что придет оно в целости - да и то с точки зрения соответствующего алгоритма. В общем как я понял мораль в том чтоб не отрываться от реального мира :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 12:53 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строку В общем как я понял мораль в том чтоб не отрываться от реального мира :-) Мораль в том, что "все абстракции дырявы"(с) и, как следствие, школьник тыкающий мышкой в дельфи IDE всегда обязан "сначала выучить как тоже самое делать без"(с) IDE. Очень похоже на реальную картину? :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 13:11 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Вообще-то, автор статьи - зануда. Талдычит одно и то-же. Дескать абстрагируйтеся .. детки токо .. не сильно. Не забывайте могилы своих предков. Хе-хе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 13:35 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
лыко в строкуВ общем как я понял мораль в том чтоб не отрываться от реального мира :-) Не буду гадать о морали в целом, но в данном случае я имел в виду следующее: Но в один прекрасный день они напишут "foo"+"bar", и возникнут странные проблемы, а мне придётся всё равно объяснить им, что такое char* ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 13:38 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
softwarerИ в чем же отличия этой модели от других моделей ООП - те отличия, на основании которых Вы так относите? Почитайте про Zonnon. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2005, 18:48 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Worobjoff softwarerИ в чем же отличия этой модели от других моделей ООП - те отличия, на основании которых Вы так относите? Почитайте про Zonnon. И? Посмотрел концепции, посмотрел исходники. Если честно - ничего интересного. Пожалуй, нашел ответ на вопрос "чем Zonnon отличается от чего-то другого". А вот характерных особенностей именно страуструповской модели - увы. Вообще такой персонаж не упомянут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2005, 00:25 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
>>Куда ни глянь - кругом: требуется Delphi, требуется Delphi, требуется Delphi, требуется Delphi..... однако если взглянуть на софт, которым вы пользуетесь в жизни процентов 90% он выполнен на C/С++ Интегратор > --Писать серьёзные бизнесс приложения сейчас на С++ ? Извините но это маразм. Нет достойного АПИ и скорость разработки роставляет желать лучшего. Я на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. это миф, которые твердят каждый день как мантру любители дельфи. Уж и не знаю кто их этому их научил. STL, автопоинтеры придумали уже не помню когда. >softwarer >Мне кажется, что он все время излишне разбрасывался; на C++Builder, потом на Java Builder, на прочие проекты, и в результате больше ничего не делал действительно хорошо. вам слово Oracle ничего не говорит ? какжется база номер 1 уже десятилетия. А основной продукт для разработчков там какой ? - Java Builder >c127 >Фортран и сейчас интенсивно используется в своей области и ничего более удобного для флоат вычислений все еще не придумали когда-то в силу синтаксиса фортран имел лучшие оптимизатора кода, что действительно делало его самым быстрым, последние компиляторы, особенно интела делают код ничем не хуже. вторая причина - ряд алгоритмов, написанных на фортране имеет статус законодательного в ряде стран и поэтому Фортран еще много лет будет использоваться, как и как кобол. Di_LIne SarinТы с теорией хаоса знаком? Не-а... И что, есть реальные финансовые проекты построенные на ее основе? конечно есть - моделирование фитуации на бирже. Di_LIne Sarin IBM просрала много чего. Но IBM, пока по крайней мере, сила с которой нельзя не считаться. Во! Эт другое дело! Речь Мужа, а не мальчика. И ее сила, имхо, не в области софтвера лежит. DB/2 и масса софта в области коммерции та же OS/2 в половине банкоматов живет. --Гавриленко Сергей Алексеевич --У тех, кто сидит на маках отношение к майкрософту, если мягко сказать, пренебрежительное, это факт это у них снобизм, такой же как и линуксоидов. >>softwarer >>Лучший. Microsoft C регулярно выигрывал в различных замерах на эффективность генерируемого кода. В отдельных тестах вперед вырывались другие не просто вырывались - а были на голову выше. Тот же Ватком. >>Какая оболочка? У Microsoft C не было оболочки, он был command line-овый. Его оболочка называлась Quick C; предполагалось, что программист сначала в этом IDE набивает-отлаживает, а потом компилируется Microsoft C и получает эффективный продукт вас кто-то обманул - у QuickC был свой компилятор, довольно слабый. >>В данном случае выиграл правильный маркетинг. Microsoft сначала привлек к себе профессионалов - своим компилятором маркетинг заклчался в том, что МС раздавала свои продукты университетам налево и направо. и Б сильно в этом проиграла. Иммено потому и МАК выжил, потому образовательная программа в США закупала только маки. >>Кобол - Ну и конечно он навсегда останется в истории программирования благодаря замечательному оператору ALTER..PERFORM, если не наврал :) он и сейчас сейчас успешно развивается и выпушен для .NET >> T-SQL - подчеркнутый потомок бейсика; зачем в нем собаки я не знаю, но помню как факт, что аналогичный синтаксис был в ряде "встроенных" бейсиков начала девяностых. вы с ума сошли, никаких сходств ни синтаксических ни идеалогических там нет. префикс @ только у переменных, чтобы отличить их от названий имен сиквела Типа поле, таблица ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2005, 18:39 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
2softwarer Если рассматривать историю, то получится примерно так: был Microsoft с компиляторами Microsoft C, Quick C, Microsoft Pascal и Quick Basic. Был Borland с продуктами Turbo C, Turbo Pascal и Turbo Basic. Ну и были прочие производители, в основном с C - Zortech, Lattice, Watcom, еще кто-то. В этом противостоянии Microsoft имел несколько лучший компилятор C и много худший компилятор паскаля. Соответственно, Quick C и Microsoft Pascal почили в бозе и Microsoft начал давить своим лучшим продуктом - Microsoft C - одновременно поддерживая бейсик "для полноты линейки". Насколько мне известно, история изложена неточно/неверно Microsoft C того времени - это упомянутый Вами Lattice, никаких особых достоинств он не имел. По слухам Turbo C тоже происходит не из Borland (как и Pascal), не думаю, что он уступал тогдашнему MSC. По поводу MS Pascal&Turbo Pascal можно спорить, имхо и то и другое - не слишком разумные расширения Pascal, возможно Borland был более разумен. Оба обладали примерно одинаковой эффективностью (скорость работы и качество кода). И кстати обе системы были весьма малы (О TP достоверно известно, что он зачем-то был написан на ASM, MSP скорее всего тоже, но это уже мой домысел). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 15:42 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
2Lepsik вам слово Oracle ничего не говорит ? какжется база номер 1 уже десятилетия. А основной продукт для разработчков там какой ? - Java Builder Наверное одно досятилетие, но и это очень много. А вот насчет Java Builder (JDeveloper?) , это так? От формса все ушли? >c127 >Фортран и сейчас интенсивно используется в своей области и ничего более удобного для флоат вычислений все еще не придумали когда-то в силу синтаксиса фортран имел лучшие оптимизатора кода В силу синтаксиса более эффективен си (см. операторы типа += и т.д.). Фортан был эффективен из-за другого - в нем не было ссылок (указателей) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 15:51 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
*2Lepsik когда-то в силу синтаксиса фортран имел лучшие оптимизатора кода В силу синтаксиса более эффективен си (см. операторы типа += и т.д.). Фортан был эффективен из-за другого - в нем не было ссылок (указателей) в что-то все смешали в кучу. я говорил про оптимизатор кода. фортран генерировал более оптимальный код для одинаковых конструкций, написанных на обоих языках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2005, 22:21 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
* В силу синтаксиса более эффективен си (см. операторы типа += и т.д.). Фортан был эффективен из-за другого - в нем не было ссылок (указателей) Ссылки с указателями тут при чем? Насчет скорости +=, то по-моему это легенда от Кернигана и Ричи. Уж если оптимизатор научили выносить повторяющиеся вычисления из цикла, то не таскать в вырахении Y=Y+Z лишний раз значения переменных из регистра в память и обратно он как-нибудь сумеет. Это же более простая задача, тут вообще нечего делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2005, 04:43 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Во - блин замутили!!! Получается, что Керниган и Ричи в MS или БорМанде работали ??? Читая посты к такому выводу приходишь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2005, 07:25 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Те кому пришлось кодить на ассемблере ДВК, не умиляются этим операторам +=, -= ... языка С. И не удивляются побочным эффектам некоторых операторов. Ведь это все - машинные команды процессора PDP-11 Это потом, когда С перевели на Intel (с очень бедной системой команд), эти операторы стали казаться достижением науки. Кернигиан и Ритчи просто развивали ассемблер пытаясь довести его до языка высокого уровня... Как им это удалось, можно судить по объему стандарта языка С. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2005, 14:27 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Ну коль заговорили о PDP-11... Тогда куда отнести язык структурного программирования Макро-32? Это VAX-11; дальнейшее развитие линейки 11 - DEC. Далее - язык структурного программирования Макро-64 (Alpha) Размер описания можно оценить: http://h71000.www7.hp.com/doc/82final/5601/5601PRO.HTML или http://h71000.www7.hp.com/doc/82final/5601/aa-pv64e-te.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2005, 19:11 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Lepsik softwarerМне кажется, что он все время излишне разбрасывался; на C++Builder, потом на Java Builder, на прочие проекты, и в результате больше ничего не делал действительно хорошо. вам слово Oracle ничего не говорит ? какжется база номер 1 уже десятилетия. А основной продукт для разработчков там какой ? - Java Builder Плюньте в лицо тому, кто сказал Вам такую глупость :) Во-первых, не Java Builder, а JDeveloper. Во-вторых, "основной" он только в мечтах маркетологов Oracle. Он там настолько основной, что его недавно сделали бесплатным - только чтоб как-то им пользовались и стимулировали этим покупку того, с чем он хорошо интегирован - в первую очередь Portal и BPEL Modeller. Ну и вопрос на засыпку - Вы с ним работали? Как впечатление? Я вот, к моему сожалению, работаю. Lepsik softwarerКакая оболочка? У Microsoft C не было оболочки, он был command line-овый. Его оболочка называлась Quick C; предполагалось, что программист сначала в этом IDE набивает-отлаживает, а потом компилируется Microsoft C и получает эффективный продукт вас кто-то обманул - у QuickC был свой компилятор, довольно слабый. Точнее, Вы пытаетесь приписать мне то, чего я не говорил. Безусловно, был, слабый, но быстрый. По мысли мелкософтовцев чувак работал в IDE Quick C, а когда доводил код до ума - компилил Microsoft C и клал в библиотеку. Lepsik>>Кобол - Ну и конечно он навсегда останется в истории программирования благодаря замечательному оператору ALTER..PERFORM, если не наврал :) он и сейчас сейчас успешно развивается и выпушен для .NET "Успешно развивается" и "не до конца закопан" - разные вещи. Примерно настолько Lepsik>> T-SQL - подчеркнутый потомок бейсика; зачем в нем собаки я не знаю, но помню как факт, что аналогичный синтаксис был в ряде "встроенных" бейсиков начала девяностых. вы с ума сошли, никаких сходств ни синтаксических ни идеалогических там нет. Будем считать, Вам виднее. Примерно насколько же, насколько с явабилдером. Lepsik префикс @ только у переменных, чтобы отличить их от названий имен сиквела Типа поле, таблица Хм. Сама по себе спорная мысль. Но пожалуй это основное, что отличает его код от бейсиковского. Впрочем, Вам по-прежнему виднее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2005, 14:50 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
*Насколько мне известно, история изложена неточно/неверно Microsoft C того времени - это упомянутый Вами Lattice, никаких особых достоинств он не имел. Полагаю, сейчас трудно будет сравнить и решить, являются ли достоинства "особыми". Скажем так, программисты куда опытнее меня, с которыми я в то время был знаком, именно его ценили больше других; также и по моим замерам в районе 90-го года остальные выигрывали у него в отдельных областях, проигрывая по сумме качеств. *По слухам Turbo C тоже происходит не из Borland (как и Pascal), не думаю, что он уступал тогдашнему MSC. Согласитесь, "думать" можно что угодно. Borland стал собой на идее IDE. Он взял хейлсберговский компилятор - и чуть ли не за год выполз в лидеры рынка, приписав к нему оболочку. Дальше они хорошо, серьезно улучшали и компилятор, и библиотеки, но локомотивом тем не менее был интерфейс. Для паскаля, как впоследствии для дельфы, такой подход был оптимален. Но для Си - пожалуй, было недостаточно. *По поводу MS Pascal&Turbo Pascal можно спорить, имхо и то и другое - не слишком разумные расширения Pascal, возможно Borland был более разумен. Microsoft Pascal попросту был сиротой, продуктом без присмотра. Виртовский по возможностям и настолько я помню, так и оставшийся комманд-лайновым - вряд ли он мог конкурировать с Turbo без кардинального усиления. К тому же Borland набрал инерцию на Z80-персоналках, на которых Turbo Pascal был не то что популярен, а доминировал. *О TP достоверно известно, что он зачем-то был написан на ASM, А на чем же еще, по-Вашему, его было писать? Для Z80 альтернатив небогато - либо бейсик, либо ассемблер :) Не говоря уже о том, что требовалось драться за каждый такт. Просто как факт - скорости паскалевского Write не хватало, чтобы нормально для глаза сделать вывод полноэкранного редактора (я писал его в те времена); пришлось сделать inline функцию в машинных кодах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2005, 15:14 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Lepsik Интегратор > --Писать серьёзные бизнесс приложения сейчас на С++ ? Извините но это маразм. Нет достойного АПИ и скорость разработки роставляет желать лучшего. Я на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. это миф, которые твердят каждый день как мантру любители дельфи. Уж и не знаю кто их этому их научил. STL, автопоинтеры придумали уже не помню когда. Оба-на! Экс - колхозник от IT выполз! Чтобы разместить объект в контейнере STL он должен обладать семантикой значений. Если делать семантику значений для каждого класса чтобы его можно было хранить в коллекциях STL по значению, не размещая в куче, то тогда производительность разработки будет хреновенькой. Что там надо? Как минимум конструктор копирования и operator=(). Кроме того, все ссылки на внутренние сущности должны быть подсчитаны - чтобы каждый указатель, открытый хендл мутекса или файла был освобожден ровно один раз, как только последний экземпляр объекта, наксеренный конструктором копирования и operator=() вызвал свой деструктор. Конструктор копирования и operator=() - это дублирование кода, т.к они пишутся раздельно. Дублирование кода требует очень аккуратного кодинга и отслеживанием одного и того же в двух местах. Если operator=() реализовать через конструктор копирования, то тогда мы сделаем адом жизнь авторов производных классов. Вызов конструктора копирования, который вызовет конструкторы копирования всех внутренних смарт-указателей, вместо того чтобы просто скопировать 32 бита, которые занимает указатель, это жопа по производительности. Я уже и не говорю про то что коллекции значений в отличии от коллекции указателей не полиморфны. Про смарт - указатели... Подсчет ссылок - это единственный надежный способ реализации смарт-указателя в С++, и я не вижу причин чтобы аффтарам С++ не внедрить этот многострадальный счетчик в объекты на уровне языка. Взяли бы и сделали к примеру квалификатор refcounted для классов. Garbage Collection в С++ не сделать - для этого надо проинтроспецировать кадый объект на предмет хранимых там указателей, а таких средств С++ не имеет. И про какие смарт-указатели мы говорим? В std:: их нет. std::auto_ptr не является copy constructable и assignable. Есть boost::shared_ptr и Loki::SmartPtr. Как ни странно, мне второй нравится больше - он хотя бы пользуется спулом для мелких объектов для размещения там счетчика ссылок. boost::shared_ptr безо всякого стеснения аллокирует объект размером в 32 бита плюс огромный хвост служебной информации, которую С++ менеджер памяти цепляет к каждому объекту, в куче. Don Clungston из codeproject.net рассказывал про большой проект написанный с плотным использованием boost:: и про то как там половина памяти быля поглощена мелкими вспомогательными объектами буста. Кроме того, boost:: стандартную поставку пока не входит. Для Loki нужен хороший компилятор. Сами фанаты С++ и повторяют как мантру свои заклинания про STL и смарт - указатели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2005, 21:33 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
LepsikИнтегратор > --Писать серьёзные бизнесс приложения сейчас на С++ ? Извините но это маразм. Нет достойного АПИ и скорость разработки роставляет желать лучшего. Я на вас посмотрю как вы будете в большом проекте сутками искать утечки памяти или отлавливать обращение по висячему пойнтеру. это миф, которые твердят каждый день как мантру любители дельфи. Уж и не знаю кто их этому их научил. STL, автопоинтеры придумали уже не помню когда. Я на дельфи не пишу - на данный момент в 95% случаев на С++ :). Если Вам STL хватает на все 100% могу вам только позавидовать :) А вот мне как не хватает знаете ли нормально Гуёвой либы и мапперов :) Ну много ещё чего конечно.... И знаете, раздражает необходимость тащить куча исходного чужогокода что бы включить стороний функционал, я видите ли хочу компонент хочу :). И раздражает извратность КОМа на С++. И обращение по висячему пойнтеру в недрах проекта не нравится отлавливать... Вы скажете что со всем этим можно более- менее укспешно бороться... Да можно, иначе не просидел бы я года на С++ и не написано было бы столько серьёзного мофта на плюсах, да вот только зачем бороться когда можно вообще забыть об этих проблемах как о страшном сне ? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2005, 11:35 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
2 softwarer Я имел ввиду QuickPascal. В нем были и command-line и IDE и немного странное ОО-расширение. Если интересно, его можно найти в инете (http://pascal.sources.ru/museum/index.htm). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2005, 14:28 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
*2 softwarer Я имел ввиду QuickPascal. Об этом проекте, к сожалению, абсолютно ничего не знаю и соответственно не могу ничего сказать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2005, 15:26 |
|
||
|
Delphi - универсальнейший инструмент разработки?
|
|||
|---|---|---|---|
|
#18+
Сергей Ильич Оба-на! Экс - колхозник от IT выполз! это что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2005, 23:14 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1347403]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
131ms |
get topic data: |
9ms |
get forum data: |
4ms |
get page messages: |
173ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 591ms |

| 0 / 0 |
