В Go := не является присваиванием как раз, в отличае от Паскаля. В Go := является объявлением переменной c одновременной её инициализацией, а не присваиванием.
Кстати, если статья рассчитана на начинающих программистов, то код в статье должен быть вылизан идеально.
Таким же кодом как в статье (ComboBox1, вот этот вот унылый if и прчее) вы прививаете начинающему делфипрограммеру дурные манеры. Вы ему как бы говорите — смотри, парень, так прокатывает даже в статье! Так что к тебе то спросу и вовсе не будет! Так писать — норма!
В итоге люди которые не знакомы с делфи (либо уже предвзято к делфи относятся) смотрят на статью, и делают вывод — что даже в статье по делфи быдлокод, значит средний делфикодер накодит вообще страх и ужас => делфикодеры недопрограммисты.
А люди которые только начинают на делфи программировать переймут эту же манеру писать и будут уже на рабочих местах таки доказывать что да, делфикодеры это недопрограммисты.
Таким образом, статья в нынешнем виде является антирекламой делфи.
Только нужно учесть, что эта либа распространяется под GPL v2 или выше так как оригинальный код Ares Galaxy был под GPL 2. Следовательно и, например, клиент описанный в данной статье, также будет под GPL, равно как и любая другая программа которая будет использовать эту либу.
PS. Кстати, автору неплохо бы указать лицензию на sf.net явным образом.
Уже не первый раз убеждаешься в том, что все нервные крики в сторону Delphi – это просто бред и комплексы фанатов С++ (данная фраза проверена этическим комитетом; выдана справка о том, что провокационной она не является, будучи написанной автором в состоянии аффекта – Прим. ред). На Delphi можно написать практически любую программу, будь то компактная хакерская тулза или продвинутая программа для работы с БД.
И второй:
Для первой части статьи я писал пример на моем любимом Delphi, но сегодня мне предстоит ему изменить и воспользоваться великим и могучим C#. Многие Delphi-ненавистники возрадуются и громко закричат: «Неужели на Delphi нельзя создать полноценный клиент?». Вовсе нет, на Delphi можно написать практически любое приложение и торрент-клиент – не исключение, но есть одно но. Как ты понимаешь, протокол BitTorrent – это не хухры-мухры и просто так реализовать его в приложении не удастся. В настоящее время для дельфина не существует ни одной нормальной библиотеки/модуля для упрощения взаимодействия с этим протоколом. Все те библиотеки, которые мне попадались на глаза, морально устарели и требовали переписывания до 60% кода.
Из этого сделать вывод, что «на делфи невозможно написать торрент-клиент» может сделать только «программист», руководствующийся принципом «это невозможно сделать, если для этого не написано готового компонента/библиотеки».
Не думал что делфисты, в массе своей, имеют настолько низкую квалификацию. Что они настолько не знают инструмент которым пользуются, и его возможности, что могут из подобных вот статеек сделать такие вот выводы.
PS. И да, обзор архитектуры и особенностей библиотеки для торрента, писанной на Delphi был бы намного интересней, чем статья про лепления гуйни к готовой уже библиотеки. Уж что лепка гуйни на делфи возможна, думаю, знают даже делфисты.
Что дельфи умеет сеть было известно ещё году в 2003, когда спамеры заюзали инди либу для своих спам ботов. Кажется кип на дельфях был писан.
Это вообще было известно сразу после появления делфи — там же есть полный (или почти полный) биндинг к WinAPI. В том числе и к сети. А если вдруг биндинга нужного нет, то всегда можно сделать — биндинги к сишному добру там делаются элементарно (как и в куче других ЯП).
В каком месте тут можно было усомниться в возможности на делфи написать торрент-качалку, не ясно.
Тем более что там явно же enum нужно отобразить в число, а еще точнее, в ID картинки. Поскольку мы полностю контроллируем и именование/нумерацию наших картинок, и enum, думаю легко можно было бы весь этот код превратить в одну строчку преобразования из одного в другое.
На самом деле, честнее было бы показывать скриншоты с одним и тем же валпапером, либо нужны скриншоты где валпапера не видно вовсе, зато видно много приложений открытых разнообразных.
Ибо именно фоновая картинка тут создает 90 процентов эффекта, а изменение темы — это изменение стиля всех окон и контролов у всех приложений пользующихся стандартными контролами, чего на представленных скриншотах практически и не видно как раз.
Не примите на неуважение к вам, или лично к Никлаусу Вирту, но складывается впечатление, что месяц назад где-то разломало стену, за которой сидели оберонщики. Они не видели мира современного программирования, мир не видел их, а потому они сейчас воспринимаются как миссионеры-фанатики…
В королевстве делфи так вообще отдельный отдел про Оберон имеется (там практически каждый тред был эпичным): www.delphikingdom.com/oberon
То есть вопрос не в том, почему про Оберон никто давно не слышал, и где оберонщики все это время были — были они практически на каждом профессиональном программерском ресурсе и активно несли «свет в массы», вопрос в том, почему хабре про это все это до сих пор не слышали :-)
Ну ничего, теперь Оберон и на хабре! Ура, товарищи! :-)
Фирма Xilinx с капитализацией в миллиарды долларов попросила написать статью в их журнал. Тут же некая фирмочка, тоже американская — Saalima Electronics подхватила идею и реализовала систему на более современной плате. И что интересно, ни у Xililnx, ни на форуме Saalima я не заметил ни одного высказывания в стиле «миссионеры фанатики, да что они знают о жизни».
Просто уточню, что эта самая Saalima она всего лишь перенесла на свою плату этот проект (что, кстати, довольно хорошо, ибо девборды Spartan-3 больше не производятся, и соответственно стоят уже баксов 300 (и еще баксов 100 стоит шнурок для разработки)): pipistrello.saanlima.com/index.php?title=Welcome_to_Pipistrello При этом на этой плате все тот же Xilinx. Это уже Spartan-6. Стоит плата порядка 160$
Ок. А писать код под какой-нибудь CISC или там VLIW? ;-)
Я к тому, что не очень понятно как твое высказывание соотносится с моим, и вообще со статьей. В статье Вирт рассказывает как он слепил цельную систему целиком, начиная от FPGA и заканчивая языком и осью. Получилась вполне себе такая вещь в себе. Неплохая моделька для обучения (как основам того как CPU работают и комп целиком, так и ЯП и ОС — эдакий вводный курс), экспериментов и всякого разного фанатского DIY (в виртовском этом компе реализована (на верилоге) и SPI, куда по умолчанию втыкается модуль nRF24L01+, то есть на этом компе довольно удобно опрашивать например датчики в доме которые передают показометры через nRF24L01+. Хотя, конечно через тот же raspberry pi можно соорудить в точности то же самое. В виртовском компе все будет прозрачней и понятней и более кастомизируемо, в PI будет больше ресурсов, больше софта, более приятные ЯП и проч).
Каким боком тут рассуждения на чем писать под avr/arm я не очень понимаю. Если мне надо по работе что-то писать под какой-нибудь msp430 или arm, то я возьму скорее всего те тулзы, которые рекомендует производитель, где больше вменяемой документации и где я быстрее достигну результата. А уж что именно это будет — С++, Си, Асм, модула, или Ада — мне в принципе всё равно. Тем более что статья то не про это.
Флешбек двадцатилетней давности. Ночи за Turbo C, Turbo Pascal и Turbo Debugger от Borland. Отсутствие интернета, фидо у везучих друзей с телефоном, переводные журналы…
Ностальгия и романтика! Здорово ведь! Разве нет? ;-)
Слишком много свободного времени, это в комментах переливать из пустого в порожнее на протяжении 100500 комментов ссылаясь на авторитетов и на отсутствие личного опыта у аппонентов :-)
А тут — провел эксперимент, установил факт, и всё :-) Экономия кучи времени.
На самом деле многие утверждения, звучавшие во всех тих обероновских обсуждениях могут быть опровергнуты (либо не опровергнуты) экспериментом.
Кстати, из моих экспериментов также можно сделать вывод, что в объектнике нигде нехранится ни номер сборки который бы инкрементировался со временем при неизменном интерфейсе модуля, ни дата/timestamp сборки.
Поэтому ещё раз повторяю, глянь исходники проектов на других языках, относящимся к этому времени, и часто увидишь то же самое.
Ок. Глянул. Глянул в те исходники той группы рузработчиков, у которой Вирт неоднократно заимствовал идеи и черпал вдохновение, без этой группы разработчиков никогда у Вирта оберона бы не случилось. Впрочем черпал идеи у них не он один. Я говорю о Xerox Park.
Итак, вот код 1981 года (то есть за 8 лет до релиза первого оберона, и за 6 лет до начала его написания, то есть тогда Оберона еще и в проекте не было). Язык программирования тут конечно же Mesa:
VerbalizeFtpError: PUBLIC PROCEDURE [ftpError: FtpError, message: STRING] =
BEGIN
-- Note: Appends message to string.
-- append message to string
SELECT ftpError FROM
IN CommunicationError => VerbalizeCommunicationError[ftpError, message];
IN CredentialError => VerbalizeCredentialError[ftpError, message];
IN FileError => VerbalizeFileError[ftpError, message];
IN DumpError => VerbalizeDumpError[ftpError, message];
IN MailError => VerbalizeMailError[ftpError, message];
IN ClientError => VerbalizeClientError[ftpError, message];
IN ProtocolError => VerbalizeProtocolError[ftpError, message];
IN InternalError => VerbalizeInternalError[ftpError, message];
ENDCASE => VerbalizeUnidentifiedError[ftpError, message];
-- IN UnidentifiedError
END;
И вот еще:
RemoveDeviceFromChain: PUBLIC ENTRY PROCEDURE [network: Network] =
BEGIN
tail: Network ← firstNetwork;
IF useCount > 0 THEN
BEGIN
DriverDefs.GetPupRouter[].removeNetwork[network];
DriverDefs.GetOisRouter[].removeNetwork[network];
network.deactivateDriver[];
END;
IF state = ready THEN UnlockCode[network.interrupt];
IF firstNetwork = network THEN firstNetwork ← network.next
ELSE
BEGIN
UNTIL tail.next = network DO tail ← tail.next; ENDLOOP;
tail.next ← network.next;
END;
-- network.index is not updated. It is used only to collect Gateway statistics.
END;
И более-менее нормальное форматирование, и нормальные именования переменных, и даже коментарии в коде.
Алексей, не стоит упирать на число 2013 в названии Project Oberon 2013 — коду в этом проекте более 20-ти лет.
Сергей, я люблю точные формулировки, иначе легко ошибиться. То о чем ты выше говорил для Оберона образца 2013 года просто не действительно. Я знаю эту систему (да-да, 2013 года), ты её не знаешь, как показала практика. Нельзя говорить о оберонах вообще когда рассматривается данный конкретный представитель. Ну нельзя. Иначе я могу сказать что и в Си-системах информация о именах переменных также в бинаре содержатся — это будет иметь ровно ту же степень истинности что и твое высказывание.
Если в текущем учебном проекте такого нет (сейчас(lа и в ближайшие 2-3 недели) проверить не смогу, то Вирт следовал простому правилу, сделать, как можно проще для обучения — есть основная концепция выдачи отладочной информации, минимальная, но полностью понятная.
Да… То есть если Вирт хранит имена переменных в бинаре, то это конечно потому, что он заботится о том, чтобы было проще программировать, чтобы можно было посмотреть состояние системы после краха и понять в чем дело, это избавляет От необходимости пошаговой отладки! Круто! Вирт молодец!
Если Вирт НЕ хранит имена переменных и нет возможности инспекции состояния системы после краха, то Вирт просто следует принципу максимальной простоты. Вирт снова молодец!
Предлагаю сюда добавить также, что и стиль кодирования Вирта тоже прекресен именно потому, что он становится легко переносим между этими двумя концепциями — даже если мы будем сохранять имена переменных в бинаре, то это будет минимальный оверхед из за стиля программирования Вирта. Вирт и тут молодец!
Похоже что бы Вирт не делал всегда найдется объяснение почему Вирт в этом случае молодец, а все остальные, мейнстримщики, просто не понимают глубину его мысли :-)
Честное слово, лучше бы он просто по нормальному отрефакторил свой код — одно это уже СИЛЬНО снизило бы сложность системы для изучения. При том что объем бинарников никак бы не изменился.
Да. То есть в данном конкретном проекте, Project Oberon 2013 и далее, использование коротких невнятных названий переменных, лепление множества statement'ов на одну строку ничем не оправданы.
То есть это можно объяснить тем, что Вирт так привык делать, что он бОльшую часть кода позаимствовал из Project Oberon 1989, где это еще на что-то влияло, и так далее. Но факт остается фактом — Project Oberon 2013 от такого стиля кодирования автора сильно страдает. Проект оказывается неоправданно сложным для восприятия того, кто его будет изучать (например студента), более того, есть шанс, что человек посмотрит на это дело, и решит что именно так и есть правильно (и я это уже наблюдал — некоторые оберонщики именно в таком стиле и пишут, сейчас. В 2015 году. В винде например).
Конечно если бы Вирт переписал код с нормальными идентификаторами, и с нормальным форматированием кода, то те метрики которые он приводит вначале книжки (про то, сколько там строчек кода в системе, какой объем исходников, какое все мелкое и компактное получилось) несколько испортились бы. По моим оценкам, они стали бы хуже процентов на 30.
Таким образом, я бы стал рекомендовать эту книжку и ОС для обучения только либо после того, как код в ней будет приведен к нормальному стилю кодирования (рефакторинг rename + автоформатирование), либо только как часть курса «учимся разбираться и рефакторить древний говнокод». Иначе Project Oberon 2013 может нанести больше вреда чем пользы.
В Go := это вообще не присваивание. Это инициализация + объявление переменной.
А вот присваивание в Go это =
Таким же кодом как в статье (ComboBox1, вот этот вот унылый if и прчее) вы прививаете начинающему делфипрограммеру дурные манеры. Вы ему как бы говорите — смотри, парень, так прокатывает даже в статье! Так что к тебе то спросу и вовсе не будет! Так писать — норма!
В итоге люди которые не знакомы с делфи (либо уже предвзято к делфи относятся) смотрят на статью, и делают вывод — что даже в статье по делфи быдлокод, значит средний делфикодер накодит вообще страх и ужас => делфикодеры недопрограммисты.
А люди которые только начинают на делфи программировать переймут эту же манеру писать и будут уже на рабочих местах таки доказывать что да, делфикодеры это недопрограммисты.
Таким образом, статья в нынешнем виде является антирекламой делфи.
PS. Кстати, автору неплохо бы указать лицензию на sf.net явным образом.
iantonov.me/page/programmiruem-torrent-klient-na-delphi
iantonov.me/page/programmiruem-torrent-klient-na-sdelphis-c
Процитирую отрывок из первой
И второй:
Из этого сделать вывод, что «на делфи невозможно написать торрент-клиент» может сделать только «программист», руководствующийся принципом «это невозможно сделать, если для этого не написано готового компонента/библиотеки».
Не думал что делфисты, в массе своей, имеют настолько низкую квалификацию. Что они настолько не знают инструмент которым пользуются, и его возможности, что могут из подобных вот статеек сделать такие вот выводы.
PS. И да, обзор архитектуры и особенностей библиотеки для торрента, писанной на Delphi был бы намного интересней, чем статья про лепления гуйни к готовой уже библиотеки. Уж что лепка гуйни на делфи возможна, думаю, знают даже делфисты.
Это вообще было известно сразу после появления делфи — там же есть полный (или почти полный) биндинг к WinAPI. В том числе и к сети. А если вдруг биндинга нужного нет, то всегда можно сделать — биндинги к сишному добру там делаются элементарно (как и в куче других ЯП).
В каком месте тут можно было усомниться в возможности на делфи написать торрент-качалку, не ясно.
Ибо именно фоновая картинка тут создает 90 процентов эффекта, а изменение темы — это изменение стиля всех окон и контролов у всех приложений пользующихся стандартными контролами, чего на представленных скриншотах практически и не видно как раз.
Кстати, я не знаю почему именно на хабре про оберон до сих пор не говорили, в этом плане хабр был в некотором роде, в изоляции, но вот например на rsdn обероносрачики были еще в 2004 году: rsdn.ru/forum/philosophy/860619.all rsdn.ru/forum/philosophy/896790.all
Да и в 2003 народ про Оберон и литературу про него тоже спрашивал: rsdn.ru/forum/other/207807.all
А вот например 2012 год: rsdn.ru/forum/philosophy/4807524.flat.1
На тему Оберона и rsdn даже на лурке кое-что есть (см. первый же мем): lurkmore.to/RSDN#.D0.9C.D0.B5.D0.BC.D1.8B
В королевстве делфи так вообще отдельный отдел про Оберон имеется (там практически каждый тред был эпичным): www.delphikingdom.com/oberon
То есть вопрос не в том, почему про Оберон никто давно не слышал, и где оберонщики все это время были — были они практически на каждом профессиональном программерском ресурсе и активно несли «свет в массы», вопрос в том, почему хабре про это все это до сих пор не слышали :-)
Ну ничего, теперь Оберон и на хабре! Ура, товарищи! :-)
Просто уточню, что эта самая Saalima она всего лишь перенесла на свою плату этот проект (что, кстати, довольно хорошо, ибо девборды Spartan-3 больше не производятся, и соответственно стоят уже баксов 300 (и еще баксов 100 стоит шнурок для разработки)): pipistrello.saanlima.com/index.php?title=Welcome_to_Pipistrello При этом на этой плате все тот же Xilinx. Это уже Spartan-6. Стоит плата порядка 160$
Вот тут можно прочитать подробнее как переносили проект на эту плату: saanlima.com/forum/viewtopic.php?f=4&t=1246&start=8
Хороший фановый и пиар-проект, я считаю ;-)
Я к тому, что не очень понятно как твое высказывание соотносится с моим, и вообще со статьей. В статье Вирт рассказывает как он слепил цельную систему целиком, начиная от FPGA и заканчивая языком и осью. Получилась вполне себе такая вещь в себе. Неплохая моделька для обучения (как основам того как CPU работают и комп целиком, так и ЯП и ОС — эдакий вводный курс), экспериментов и всякого разного фанатского DIY (в виртовском этом компе реализована (на верилоге) и SPI, куда по умолчанию втыкается модуль nRF24L01+, то есть на этом компе довольно удобно опрашивать например датчики в доме которые передают показометры через nRF24L01+. Хотя, конечно через тот же raspberry pi можно соорудить в точности то же самое. В виртовском компе все будет прозрачней и понятней и более кастомизируемо, в PI будет больше ресурсов, больше софта, более приятные ЯП и проч).
Каким боком тут рассуждения на чем писать под avr/arm я не очень понимаю. Если мне надо по работе что-то писать под какой-нибудь msp430 или arm, то я возьму скорее всего те тулзы, которые рекомендует производитель, где больше вменяемой документации и где я быстрее достигну результата. А уж что именно это будет — С++, Си, Асм, модула, или Ада — мне в принципе всё равно. Тем более что статья то не про это.
Ностальгия и романтика! Здорово ведь! Разве нет? ;-)
А тут — провел эксперимент, установил факт, и всё :-) Экономия кучи времени.
На самом деле многие утверждения, звучавшие во всех тих обероновских обсуждениях могут быть опровергнуты (либо не опровергнуты) экспериментом.
Ок. Глянул. Глянул в те исходники той группы рузработчиков, у которой Вирт неоднократно заимствовал идеи и черпал вдохновение, без этой группы разработчиков никогда у Вирта оберона бы не случилось. Впрочем черпал идеи у них не он один. Я говорю о Xerox Park.
Итак, вот код 1981 года (то есть за 8 лет до релиза первого оберона, и за 6 лет до начала его написания, то есть тогда Оберона еще и в проекте не было). Язык программирования тут конечно же Mesa:
И вот еще:
И более-менее нормальное форматирование, и нормальные именования переменных, и даже коментарии в коде.
Желающие могут покопать код тут: xeroxalto.computerhistory.org/Ibis/AltoGateway
Сергей, я люблю точные формулировки, иначе легко ошибиться. То о чем ты выше говорил для Оберона образца 2013 года просто не действительно. Я знаю эту систему (да-да, 2013 года), ты её не знаешь, как показала практика. Нельзя говорить о оберонах вообще когда рассматривается данный конкретный представитель. Ну нельзя. Иначе я могу сказать что и в Си-системах информация о именах переменных также в бинаре содержатся — это будет иметь ровно ту же степень истинности что и твое высказывание.
Да… То есть если Вирт хранит имена переменных в бинаре, то это конечно потому, что он заботится о том, чтобы было проще программировать, чтобы можно было посмотреть состояние системы после краха и понять в чем дело, это избавляет От необходимости пошаговой отладки! Круто! Вирт молодец!
Если Вирт НЕ хранит имена переменных и нет возможности инспекции состояния системы после краха, то Вирт просто следует принципу максимальной простоты. Вирт снова молодец!
Предлагаю сюда добавить также, что и стиль кодирования Вирта тоже прекресен именно потому, что он становится легко переносим между этими двумя концепциями — даже если мы будем сохранять имена переменных в бинаре, то это будет минимальный оверхед из за стиля программирования Вирта. Вирт и тут молодец!
Похоже что бы Вирт не делал всегда найдется объяснение почему Вирт в этом случае молодец, а все остальные, мейнстримщики, просто не понимают глубину его мысли :-)
Честное слово, лучше бы он просто по нормальному отрефакторил свой код — одно это уже СИЛЬНО снизило бы сложность системы для изучения. При том что объем бинарников никак бы не изменился.
То есть это можно объяснить тем, что Вирт так привык делать, что он бОльшую часть кода позаимствовал из Project Oberon 1989, где это еще на что-то влияло, и так далее. Но факт остается фактом — Project Oberon 2013 от такого стиля кодирования автора сильно страдает. Проект оказывается неоправданно сложным для восприятия того, кто его будет изучать (например студента), более того, есть шанс, что человек посмотрит на это дело, и решит что именно так и есть правильно (и я это уже наблюдал — некоторые оберонщики именно в таком стиле и пишут, сейчас. В 2015 году. В винде например).
Конечно если бы Вирт переписал код с нормальными идентификаторами, и с нормальным форматированием кода, то те метрики которые он приводит вначале книжки (про то, сколько там строчек кода в системе, какой объем исходников, какое все мелкое и компактное получилось) несколько испортились бы. По моим оценкам, они стали бы хуже процентов на 30.
Таким образом, я бы стал рекомендовать эту книжку и ОС для обучения только либо после того, как код в ней будет приведен к нормальному стилю кодирования (рефакторинг rename + автоформатирование), либо только как часть курса «учимся разбираться и рефакторить древний говнокод». Иначе Project Oberon 2013 может нанести больше вреда чем пользы.