а может, ну этот freebasic нафиг!?
Участников: 5
Страница 2 из 2 • 1, 2
Re: а может, ну этот freebasic нафиг!?
Именно! Компилятор, это только компилятор. В нём должен быть основной функционал, всё же лишнее вынести в библиотеки.
Но тут есть две оговорки.
1. библиотеки могут быть статические или динамические, главное чтобы легко подключались.
2. ядро компилятора должно быть очень гибким и не ограничивать разработчика.
В какой-то мере C++ отвечает этим требованиям.
Но у него другая проблема. В первую очередь сам Страустрап требует, чтобы ядро C++ менялось только в особых случаях и было бы 100% совместимо с предыдущими версиями.
А с библиотеками твориться полный панкомат, все как хотят так и пишут. Что тоже раздражает.
У фрибэйсика другая проблема. У него много функций встроена.
На самом деле это проблема идиалогий.
В интерпретируемых языках функционал должен быть доступен максимально просто и на очень высоком уровне.
В компилируемых языках наоборот, функционал должен быть подключаемый.
Бэйсик же оказался как раз посерёдке. Ведь когда говорят бэйсик, то всплывает словосочитание "интерпретатор бэйсик". О компиляторах бэйсика все сразу же забывают.
В C++ очень много низкоуровневых фишек с которыми нужно мириться. А крайний консерватизм усложняет проблему.
Похожая ситуация с objective-c, тоже неплохой язык, но к сожалению не на mac платформах он почти не распространён.
Я вот по этому и говорю о необходимости нового языка. В прочем до этого нужно выяснить всякие ньюансы того же самого C++ и objective-C ведь у них есть офигенные вещи.
В языке D говорят тоже есть приколы. Но я до него ещё не добрался.
И повторюсь. Ядро компилятора должно поддерживать только базовый функционал, но по максимуму.
константы
переменные
указатели
ссылки
все процессорные команды
функции
классы
объекты
условные операторы
операторы циклов
другие операторы управление выполнением
приведение типов
многопоточность
пространство имён
шаблоны
обработка исключений
вставка машинного кода
изменения типа вызова функции
управление секциями памяти
взаимодействие с отладчиками и профилировщиками
Классы должны быть и статические и динамические.
Код должен и компилироваться и интерпретироваться, в зависимости от ситуации.
Плюс, на уровне компилятора кроме основных типов должны поддерживаться дополнительные.
строки
массивы
списки
вектора
стеки
буфера
словари
От некоторых вещей нужно отказаться. Например макросы, да и препроцессор вообще.
Библиотеки нужно стандартизовать.
Ещё кстати думал, что поддержка интернацинализации и локализации, должна быть более удобная. И лучше прямо на уровне ядра компилятора.
Сейчас эти проблемы решаються не очень-то красивым способом. Всякие gettext или ресурсы, прямо скажем больше походят на костыли, чем на сильные ноги, на которые можно опереться.
А, ну да, ещё нужен полный набор фундаментальных типов. Скажем прямо, те что есть не всегда достаточны.
Порой же нет даже основных, например boolean.
Про нечёткую логику или комплексные числа я вообще молчу. Их бы тоже надо сделать прямо в ядре компилятора.
Как я уже писал раньше во многих языках пытались достич этих целей. Например java. Стандартизация библиотек на очень хорошем уровне. Но у них есть и пакости. Например сборщик мусора. Да и пользовательский интерфейс свой собственный, а не родной для операционки.
Ну да, вот ещё. В заимодействие с операционкой должно быть тоже очень хорошим. Но это можно повесить как раз на библиотеки.
В Microsoft смотрят в правильную сторону. Но ещё очень мало сделали.
Но тут есть две оговорки.
1. библиотеки могут быть статические или динамические, главное чтобы легко подключались.
2. ядро компилятора должно быть очень гибким и не ограничивать разработчика.
В какой-то мере C++ отвечает этим требованиям.
Но у него другая проблема. В первую очередь сам Страустрап требует, чтобы ядро C++ менялось только в особых случаях и было бы 100% совместимо с предыдущими версиями.
А с библиотеками твориться полный панкомат, все как хотят так и пишут. Что тоже раздражает.
У фрибэйсика другая проблема. У него много функций встроена.
На самом деле это проблема идиалогий.
В интерпретируемых языках функционал должен быть доступен максимально просто и на очень высоком уровне.
В компилируемых языках наоборот, функционал должен быть подключаемый.
Бэйсик же оказался как раз посерёдке. Ведь когда говорят бэйсик, то всплывает словосочитание "интерпретатор бэйсик". О компиляторах бэйсика все сразу же забывают.
В C++ очень много низкоуровневых фишек с которыми нужно мириться. А крайний консерватизм усложняет проблему.
Похожая ситуация с objective-c, тоже неплохой язык, но к сожалению не на mac платформах он почти не распространён.
Я вот по этому и говорю о необходимости нового языка. В прочем до этого нужно выяснить всякие ньюансы того же самого C++ и objective-C ведь у них есть офигенные вещи.
В языке D говорят тоже есть приколы. Но я до него ещё не добрался.
И повторюсь. Ядро компилятора должно поддерживать только базовый функционал, но по максимуму.
константы
переменные
указатели
ссылки
все процессорные команды
функции
классы
объекты
условные операторы
операторы циклов
другие операторы управление выполнением
приведение типов
многопоточность
пространство имён
шаблоны
обработка исключений
вставка машинного кода
изменения типа вызова функции
управление секциями памяти
взаимодействие с отладчиками и профилировщиками
Классы должны быть и статические и динамические.
Код должен и компилироваться и интерпретироваться, в зависимости от ситуации.
Плюс, на уровне компилятора кроме основных типов должны поддерживаться дополнительные.
строки
массивы
списки
вектора
стеки
буфера
словари
От некоторых вещей нужно отказаться. Например макросы, да и препроцессор вообще.
Библиотеки нужно стандартизовать.
Ещё кстати думал, что поддержка интернацинализации и локализации, должна быть более удобная. И лучше прямо на уровне ядра компилятора.
Сейчас эти проблемы решаються не очень-то красивым способом. Всякие gettext или ресурсы, прямо скажем больше походят на костыли, чем на сильные ноги, на которые можно опереться.
А, ну да, ещё нужен полный набор фундаментальных типов. Скажем прямо, те что есть не всегда достаточны.
Порой же нет даже основных, например boolean.
Про нечёткую логику или комплексные числа я вообще молчу. Их бы тоже надо сделать прямо в ядре компилятора.
Как я уже писал раньше во многих языках пытались достич этих целей. Например java. Стандартизация библиотек на очень хорошем уровне. Но у них есть и пакости. Например сборщик мусора. Да и пользовательский интерфейс свой собственный, а не родной для операционки.
Ну да, вот ещё. В заимодействие с операционкой должно быть тоже очень хорошим. Но это можно повесить как раз на библиотеки.
В Microsoft смотрят в правильную сторону. Но ещё очень мало сделали.
Re: а может, ну этот freebasic нафиг!?
Вот все что ты описал и еще многое другое и есть Пурик.
На него кстати ходят за .dll'ками, потому что он их
компилит.
А вот еще маленькое чудо Brutus2D. В нем понравилась
работа на прямую с MIDI и возможность подключения
бибилиотек в виде dll, с заведомо известными функциями.
Но exe'шник уже от 200кб.
Если интересно тоже могу сбросить пример с exe.
На него кстати ходят за .dll'ками, потому что он их
компилит.
А вот еще маленькое чудо Brutus2D. В нем понравилась
работа на прямую с MIDI и возможность подключения
бибилиотек в виде dll, с заведомо известными функциями.
Но exe'шник уже от 200кб.
Если интересно тоже могу сбросить пример с exe.
pentod65- Сообщения : 17
Дата регистрации : 2008-11-22
Re: а может, ну этот freebasic нафиг!?
Всё что я описал?
Не может быть!
Сам же только что сказал, что пурик массивы в функциях не поддерживает!
Дык чего тут уж говорить?
А freebasic тоже dll умеет делать и статические библиотеки, причём стандартные lib*.a.
Про "много чего ещё".
Мы же ведь как раз и обсуждали, что должно быть в компилере, а чего не должно быть.
Именно вот этого "много ещё чего" не должно быть. Я так считаю.
Компилер должен уметь простые действия делать хорошо, а дополнительный функционал, типа работы с архивами, работы с аудио и видео или с базами данных можно оставить в библиотеках.
Не может быть!
Сам же только что сказал, что пурик массивы в функциях не поддерживает!
Дык чего тут уж говорить?
А freebasic тоже dll умеет делать и статические библиотеки, причём стандартные lib*.a.
Про "много чего ещё".
Мы же ведь как раз и обсуждали, что должно быть в компилере, а чего не должно быть.
Именно вот этого "много ещё чего" не должно быть. Я так считаю.
Компилер должен уметь простые действия делать хорошо, а дополнительный функционал, типа работы с архивами, работы с аудио и видео или с базами данных можно оставить в библиотеках.
Re: а может, ну этот freebasic нафиг!?
Ну это самая малость сам же сказал, что в указателях сила.
Новые версии поддерживают, но не стыкуются с наиболее
стабильной v4.0.
Упс, а почему я не знал, что Free то же умеет делать dll.
Надо поставить посмотреть.
Ну много, чего... я полностью на твоей стороне и все же
звук бы не помешал одной командой PLAY, как это сделали
в Brutus'e.
Новые версии поддерживают, но не стыкуются с наиболее
стабильной v4.0.
Упс, а почему я не знал, что Free то же умеет делать dll.
Надо поставить посмотреть.
Ну много, чего... я полностью на твоей стороне и все же
звук бы не помешал одной командой PLAY, как это сделали
в Brutus'e.
pentod65- Сообщения : 17
Дата регистрации : 2008-11-22
Re: а может, ну этот freebasic нафиг!?
Про звук...
Одной командой?
Ха-ха-ха! Не смеши мои тапочки!
И так, будет у меня супер язык
звук будет играться командой play,
Картинка рисоваться командой paint,
текст писаться командой text,
А все остальные полезные действия делать командой apport!
Если же говорить серьёзно, то для звука одной команды мало.
Звук ведь разный бывает.
Его нужно сначало загрузить из файла или ресурса.
Правильно обработав заголовок и раскодировав соответствующим методом.
Или же записать с линейного входа или микрофона.
А может быть принять через сокет по инету от друга.
Потом звук нужно обработать. Ну там убрать шумы, убрать помехи, сгладить резкие переходы, срезать эхо, выделить нужные частоты, а тех которые нет добавить.
Звук нужно воспроизвести. Но не просто так, а расположив его в виртуальном пространстве. Ну там стены всякие разные или движение, а может быть ещё что-то.
И это одной командой? Ха-ха-ха!
Только для одного звука нужна очень мощная библиотека с целой колекцией дополнительных плагинов.
А в прочем, если просто нужно проиграть вавник, то есть функция
PlaySound( filename, , NULL, SND_ASYNC | SND_FILENAME )
И она одна тоже умеет кое что делать.
Так что это не пример.
Конечно в указателях сила. Но её простите, нужно ещё с умом применять. в K&R про C написано примерно так:
C это низкоуровневый язык программирования. Он как бритва. В умелых руках великолепный инструмент. А в неумелых черезвычайно опасная вещь, которая превратит всё в кровавый фарш.
Имелись в виду и указатели.
А гибкость, удобство, можно получить заюзав всякие примочки.
классы, с наследованием и полиморфизмом.
Шаблоны функций и классов.
И прочими плюшками.
К сожалению бэйсик обделён в этом плане.
Классы ещё есть, но наследованием и не пахнет.
Про шаблоны можно и не мечтать.
Одной командой?
Ха-ха-ха! Не смеши мои тапочки!
И так, будет у меня супер язык
звук будет играться командой play,
Картинка рисоваться командой paint,
текст писаться командой text,
А все остальные полезные действия делать командой apport!
Если же говорить серьёзно, то для звука одной команды мало.
Звук ведь разный бывает.
Его нужно сначало загрузить из файла или ресурса.
Правильно обработав заголовок и раскодировав соответствующим методом.
Или же записать с линейного входа или микрофона.
А может быть принять через сокет по инету от друга.
Потом звук нужно обработать. Ну там убрать шумы, убрать помехи, сгладить резкие переходы, срезать эхо, выделить нужные частоты, а тех которые нет добавить.
Звук нужно воспроизвести. Но не просто так, а расположив его в виртуальном пространстве. Ну там стены всякие разные или движение, а может быть ещё что-то.
И это одной командой? Ха-ха-ха!
Только для одного звука нужна очень мощная библиотека с целой колекцией дополнительных плагинов.
А в прочем, если просто нужно проиграть вавник, то есть функция
PlaySound( filename, , NULL, SND_ASYNC | SND_FILENAME )
И она одна тоже умеет кое что делать.
Так что это не пример.
Конечно в указателях сила. Но её простите, нужно ещё с умом применять. в K&R про C написано примерно так:
C это низкоуровневый язык программирования. Он как бритва. В умелых руках великолепный инструмент. А в неумелых черезвычайно опасная вещь, которая превратит всё в кровавый фарш.
Имелись в виду и указатели.
А гибкость, удобство, можно получить заюзав всякие примочки.
классы, с наследованием и полиморфизмом.
Шаблоны функций и классов.
И прочими плюшками.
К сожалению бэйсик обделён в этом плане.
Классы ещё есть, но наследованием и не пахнет.
Про шаблоны можно и не мечтать.
Re: а может, ну этот freebasic нафиг!?
Ну ты дал, я же говорю, что все зависит от настроения собеседника.
Кусочек кода из Brutusa:
option explicit
dim bRunning
bRunning = True
dim mysound
dim Font1
sub main()
system.debugprint sfx.initialize
sfx.setinstrument 122
sfx.playnote 10, 4000
' Trumpet
sfx.setinstrument 56
' example of asynchronous note being played
sfx.startnote 10
system.pause (4000)
sfx.stopnote 10
' example of simultaneous notes being played
sfx.startnote 4
sfx.startnote 50
system.pause (4000)
sfx.stopnote 4
sfx.stopnote 50
sfx.terminate
end sub
Call Main
С другой стороны возможно я не прав, Brutus заточен под игрушки(весит 4м),
нужен инструмент без излишеств. Вышел пурик 4.40 в котором все есть, но
нет совместимости то же однако минус. Ты же знаешь я не супер программист,
потому спорить с тобой не буду. Подскажи, что такое Lite-C? Не пойму компилятор
или интерпритатор.
Кусочек кода из Brutusa:
option explicit
dim bRunning
bRunning = True
dim mysound
dim Font1
sub main()
system.debugprint sfx.initialize
sfx.setinstrument 122
sfx.playnote 10, 4000
' Trumpet
sfx.setinstrument 56
' example of asynchronous note being played
sfx.startnote 10
system.pause (4000)
sfx.stopnote 10
' example of simultaneous notes being played
sfx.startnote 4
sfx.startnote 50
system.pause (4000)
sfx.stopnote 4
sfx.stopnote 50
sfx.terminate
end sub
Call Main
С другой стороны возможно я не прав, Brutus заточен под игрушки(весит 4м),
нужен инструмент без излишеств. Вышел пурик 4.40 в котором все есть, но
нет совместимости то же однако минус. Ты же знаешь я не супер программист,
потому спорить с тобой не буду. Подскажи, что такое Lite-C? Не пойму компилятор
или интерпритатор.
pentod65- Сообщения : 17
Дата регистрации : 2008-11-22
Re: а может, ну этот freebasic нафиг!?
Lite-C? Насколько я знаю, это интерпритатор. И вродебы заточенный под игрушки. Я этим не очень-то интересуюсь.
Страница 2 из 2 • 1, 2
Права доступа к этому форуму:
Вы не можете отвечать на сообщения