К сожалению, мы не сможем им насладиться даже в BIOS, потому что "настоящий текстовый режим" это чёткие пиксельные шрифты, а современные мониторы видео-режим 640x480, который рендерился из текстового 80x25, интерполируют совершенно по-уродски.
Delphi - закрытая система, принадлежащая компании, о которой вы даже не слышали
Я думаю, всегда было нормально садиться на коммерческие компиляторы, что тогда Watcom или какой-нибудь Clipper, что сейчас все пишут в Visual Studio. Это не мешает (хорошим) языкам развиваться в том числе в направлении опен-сорса, и становиться мейнстримом.
А проприетарный Delphi принадлежал Никлаусу Вирту?
В 90-х рынок C++ компиляторов был поделен между Watcom, Borland, Microsoft, IBM. У каждой были свои проприетарные расширения языка, как сейчас у Delphi.
И еще один момент: если отдавать на фриланс, я могу закрыть почти весь свой код и также SQL-код
Это про dcu? Так себе решение, потому что заставляет "фрилансера" тоже использовать delphi и той же версии, что у вас. Уж лучше DLL, которую можно подключить вообще из любого языка.
Отвечаю и вам, и комментатору выше одновременно, потому что аргументы у вас схожие.
Язык не может быть проприетарным, компилятор - может. Но это не остановило C++ который был насквозь проприетарным в 90-е, а сейчас во все поля свободный и любимый. Один язык исключение? Добавим туда же java, javascript, которые sun/mozilla/microsoft пытались сделать проприетарными, да не вышло.
Был бы спрос, можно было бы быстро силами сообщества доделать Lazarus (он уже почти всё умеет, что Delphi 5, а дальше уже не принципиальные рюрешчки). Значит, кроме фанатов, оно никому и не нужно.
Всё понятно, видимо под linq вы имеете ввиду linq2objects как технологию доступа к базе. Хотя linq это намного более общий механизм в языке, который позволяет писать в стиле sql-like, оставаясь в синтаксисе c#. А так, кто мешает из другого языка подключить этот ваш DirectOracleAccess? Ну, или сокет открыть и писать туда байтики?
Да, я знаю. Но не все ставят const ))) Большинство прикладных программистов не ставит. К тому же, проблема не исчезает, если строку надо сохранить в массив, или в свойство/поле класса.
А ещё такой прикол: строковые литералы, объявленные в коде, копируются в динамическую память каждый раз при использовании. Мне было интересно, зачем так сделано, и я докопался до объяснения: якобы, строка может находиться в DLL (BPL), которая может строку куда-то передать, а потом сама DLL может быть выгружена. С тем и живём.. Теперь и вы можете мучаться и содрогаться каждый раз, используя строковый литерал в исходнике )))
К примеру, Mozilla решила переписать браузер, и взяла не Delphi, а rust, который компилируется медленнее, чем C++.
Просто разработчики системных продуктов считают, что пусть они потратят лишние часы жизни на компиляцию, зато миллиард пользователей сэкономит по 200 миллисекунд - вот и профит. А если приложение тяп-ляп и в продакшен, да изменений требований по сто раз в неделю, тут лучше быстрая компиляция, а ещё лучше - вообще интерпретатор.
От тех, кто считает наносекунды. Но таким и Delphi противопоказан. Там же - ужас, ужас - при передаче строки параметром в фунцию происходит инкремент числа ссылок на строку, а это - кошмар, кошмар - ненужный memory-traffic, вытеснение из кешей полезных данных и нагрузка на межъядерную синхронизацию кешей.
Можно каждую трансформацию данных начинать с церемонии for i := 0 to list.Count-1 do begin bla-bla end; А можно написать только то, что нужно для задачи и пойти решать следующие задачи, не распыляясь на итерации по спискам.
К сожалению, мы не сможем им насладиться даже в BIOS, потому что "настоящий текстовый режим" это чёткие пиксельные шрифты, а современные мониторы видео-режим 640x480, который рендерился из текстового 80x25, интерполируют совершенно по-уродски.
Ну вы пишете, что проблема Delphi в
Я думаю, всегда было нормально садиться на коммерческие компиляторы, что тогда Watcom или какой-нибудь Clipper, что сейчас все пишут в Visual Studio. Это не мешает (хорошим) языкам развиваться в том числе в направлении опен-сорса, и становиться мейнстримом.
Значит, нафиг никому не надо тащить в Lazarus лямбды и всё такое.
Было бы надо - развивали бы.
А проприетарный Delphi принадлежал Никлаусу Вирту?
В 90-х рынок C++ компиляторов был поделен между Watcom, Borland, Microsoft, IBM. У каждой были свои проприетарные расширения языка, как сейчас у Delphi.
Аргумент играет против вас. Зачем пилить свободные компиляторы (и не один), когда есть множество проприетарных. Один сдулся - перешёл на другой.
В вот когда проприетарный ровно один, свободный аналог надо пилить и продвигать с утроенной силой, если конечно язык хочется сохранить.
Это про dcu? Так себе решение, потому что заставляет "фрилансера" тоже использовать delphi и той же версии, что у вас. Уж лучше DLL, которую можно подключить вообще из любого языка.
С двух сторон зажат Фортраном и Ассемблером, тоже великими языками, лучшими в своих нишах.
Отвечаю и вам, и комментатору выше одновременно, потому что аргументы у вас схожие.
Язык не может быть проприетарным, компилятор - может. Но это не остановило C++ который был насквозь проприетарным в 90-е, а сейчас во все поля свободный и любимый. Один язык исключение? Добавим туда же java, javascript, которые sun/mozilla/microsoft пытались сделать проприетарными, да не вышло.
Был бы спрос, можно было бы быстро силами сообщества доделать Lazarus (он уже почти всё умеет, что Delphi 5, а дальше уже не принципиальные рюрешчки). Значит, кроме фанатов, оно никому и не нужно.
Addons\Macros\Panel.SpaceToSelect.luaЧем тогда объяснить его низкую долю на рынке? Бизнес-то денежки считает умеет, нельзя сказать что "просто не нравится".
Всё понятно, видимо под linq вы имеете ввиду linq2objects как технологию доступа к базе. Хотя linq это намного более общий механизм в языке, который позволяет писать в стиле sql-like, оставаясь в синтаксисе c#. А так, кто мешает из другого языка подключить этот ваш DirectOracleAccess? Ну, или сокет открыть и писать туда байтики?
Да, я знаю. Но не все ставят const ))) Большинство прикладных программистов не ставит.
К тому же, проблема не исчезает, если строку надо сохранить в массив, или в свойство/поле класса.
А ещё такой прикол: строковые литералы, объявленные в коде, копируются в динамическую память каждый раз при использовании. Мне было интересно, зачем так сделано, и я докопался до объяснения: якобы, строка может находиться в DLL (BPL), которая может строку куда-то передать, а потом сама DLL может быть выгружена. С тем и живём.. Теперь и вы можете мучаться и содрогаться каждый раз, используя строковый литерал в исходнике )))
К примеру, Mozilla решила переписать браузер, и взяла не Delphi, а rust, который компилируется медленнее, чем C++.
Просто разработчики системных продуктов считают, что пусть они потратят лишние часы жизни на компиляцию, зато миллиард пользователей сэкономит по 200 миллисекунд - вот и профит.
А если приложение тяп-ляп и в продакшен, да изменений требований по сто раз в неделю, тут лучше быстрая компиляция, а ещё лучше - вообще интерпретатор.
От тех, кто считает наносекунды. Но таким и Delphi противопоказан. Там же - ужас, ужас - при передаче строки параметром в фунцию происходит инкремент числа ссылок на строку, а это - кошмар, кошмар - ненужный memory-traffic, вытеснение из кешей полезных данных и нагрузка на межъядерную синхронизацию кешей.
Тут bla-bla это суть, а мне нужно избавиться от повторяющихся for
Можно каждую трансформацию данных начинать с церемонии
for i := 0 to list.Count-1 do begin bla-bla end;А можно написать только то, что нужно для задачи и пойти решать следующие задачи, не распыляясь на итерации по спискам.
Тогда ткните в документацию embarcadero, какой метод надо использовать.
Сравнивалась реализация с bitstring? Тогда может, дело в нагрузке на память?
Я на дельфи писал вложенные циклы и ничего другого мне не требовалось, потому что ничего другого язык не предоставлял.
Много теории. А на практике, однострочником можно ли перелить из одного TList в другой TList только чётные элементы?
Конкретно этот код - копирует, потому что переменная ArrSlice - не ссылочного типа, а тип-значение.