Глупост е разбира се. 68705 е от ерата преди пик-овете. Но това мнение го разбирам повече като въпрос. Погледни сериите HC08 ,HCS08 ,RS08, S12 и тогава прави сравнения.

http://www.freescale.com

Не бъркай в раната, че става страшно. Анатема.

Мирише на пърлени пикове Или МС-та

Абе напоследък се появяват доста шибани неща, от сорта на Питон, Руби и т.н. Това са точно академични езици, с почти нулева практическа стойност. Появата им е свързана със стремежа всичко да бъде описано на "един ред", особено работата със списъци и разни свързани структури. Даже напоследък се чуват гласове и стринговете да станат списъци, така де - памет има бол.



Във връзка с горното - радвам се, че си претърпял правилната промяна. Значи разните "учени" мислят точно по тоя начин - важни са алгоритмите, останалото е без значение. Тва е щото не им се е налагало да поддържат и развиват софтуер, писан от други като тях. Занаятчиите, пък, повече държат на добре написана и подредена програма, съответно лесна за поддържане. Има и трети тип - мениджърите, които не разбират нищо и на нищо не държат, с изключение на константните приходи.

Честно казано аз не съм чувал за идеален език, идеален способ за програмиране. Напротив *ВСИЧКО* си има кусури ако гледаме критично. Ако гледаме положително пък в много езици има уникални предимства. Примерно:

1. Пролог и другите ИИ-езици позволяват описване на много сложна логика, която на един алгоритмичен език и да си скъсаш задника не можеш толкова интуитивно да опишеш.
2. TCL - изключително мощно средство ако го използваш по предназначение. Какво лошо има с няколко реда код да подкараш неща за които на С ти трябват хиляди редове? Имаш супер лесен юзер интерфейс (ТК), всякакви мрежови интерфейси - буквално с един ред отваряш конекция към сървър която може да работи в отделен контекст. Това нещо на С е кошмар - трябва да пускаш нишки, да мислиш кое от къде взема памет, как се синхронизира, как се обратват грешки и т.н. Един на всеки 100 С-програмиста може и си прави труда да напише толкова надежден, защитен и ефективен код, колкото всеки начинаещ TCL-програмист може да направи с един ред код.
2. VHDL/verilog - много добре измислени езици, за съжаление с тях може да се описва само хардуер. Точно нещата които въведоха VHDL към предишното поколение HDL езици нямат аналог и липсват при езиците за програмиране и най-вече С. А именно:

1) Идеята за "архитектура" и "поведение". Това е най-близкия до човешкия ум начин за моделиране. На пръв поглед има подобна концепция и при С - една функция/обект първо се декларира после се дефинира. Но архитектурата куца сериозно. Повечето големи проекти се състоят от стотици сорс файлове и да търсиш в тях някаква архитектура е все едно да търсиш игла в купа сено. Това което липса на С-то е възможността да укажеш че нещата на грубо ниво се състоят от това, това и това и се вързват така и тал... После да вземеш едно горното ниво и да каже "а пък това на ниско ниво се състои от това и това...". И най-важното цялата архитектура да е видима от пръв поглед и да можеш да си фокусираш вниманието в определена точка. Иначе верно и на С се прави някаква йерархия с библиотеки ама няма грам прегледност, коя библиотека кои други ползва, защо ги ползва, как ги ползва и т.н. - всичко е оставено на добратя воля на програмиста да напише съвестно коментари и да не меша нещата.

2) Други аспекти като "симулация", "тест" и т.н. При Ц-то и подобните немо езици няма такова понятие изобщо. Може би донякъде се постига подобен ефект ако се свърже Ц със UML. Идеята е вземаме един блок от архитектурата - за Ц това може да е функция/клас и т.н. Имплементацията на тоя обект е равносилна на "поведение". Ако имаме "поведението" т.е. имплементацията естествено можем да го симулираме напълно. На разбираем език пускаме симулатора, стигаме до функцията и гледаме кво прави. Само че дебъгерите/симулаторите за Ц идея си нямат каква е архитектурата на проекта, кой модул (функция) от какво зависи и понякога е ужасно трудно да дебъгнем нещо реално щото се вика веднъж в годината. Докато ако имаше архитектура, щеше да има понятие "стимули" и да могат да се задават един куп неща на дебъгера, включително и той сам да се усеща какво трябва да направи с някои модули че да стигне дотам докъдето трябва.
Всичко това е в случай че имаме "поведение/имплементация", но те могат да имат алтернативни аспекти. Примерно тоя който пише заданието, може вместо да имплементира определена функция, да каже "абе тая функция връща еди кво си ако еди що си". Това до някъде е все едно да направиш куха функция която има едно "return xxx" където xxx е резултата който трябва ама е набит като константа примерно.
Хубавото на алтернативните аспекти е че още тоя който пише заданието прави "нещо щъкащо". Дори и всички блокчета по архитектурата да не са имплементирани пак може да си дебъгваш/тестваш проекта.

Знам че повечето ще кажат "а бе тва са глупости"... аз няма да споря, само ще кажа че точно тия глупости правят революции

а, питона май е много разпространен напоследък, явно си има стойност. един познат ми обясняваше разни неща за питона, в работата им мигрирали към него наскоро.
казвал съм ти аз, робовладелец от тебе няма да стане, цял живот ще бухаш на тръстиката

Тъъъй. Бейсика на МЕ няма променливи тип бит. Генерира код поне двойно по-голям от оптималния, че и повече. Хайде на Протона ! Обаче на тези образи даже демото не ще да се инсталира. Както е тръгнало май ща не искам ще докуцукам до С-то

Сито е измислено преди почти 40 год. и винаги ще е идеалния способ за програмиране. От една страна, има огромен опит в производството на компилатори и тези на големите фирми освен компилатори са и солидни експертни системи, които генерират код, който е доста по-оптимален от твоя, ако пишеш на асм. От друга страна, разширението ++ и препроцесора позволяват надграждане на езика с произволна сложност. На практика, можеш да си направиш друг език само с дефиниции, обекти и предефинирани оператори.



Можеш да си направиш хубава надстройка на C++.



Още веднъж - правиш си надстройка. Ако си по-умен - дърпаш си от нета някой готов фреймуърк. Например в един от последните си проекти ползвам curl, което е готова библиотека за работа директно с http и ftp. Допълнително самата библиотека има надстройка, наречена curl easy, която пък свежда цялата работа с http и ftp до викане на 2 ф-ии.
Та включваш нещо такова в проекта, включваш и няква надстройка за работа със списъци и имаш хем лесна мрежа, хем възможност за описание на сложна логика.



Това не са програмни езици. По принцип, програмиста винаги трябва да знае при какви условия се вика "едногодишната" ф-я и съответно да обясни на QA как да тества.

Коя е тая фирма да я избягвам?



Поживем - увидим.

123 при мен се инсталирва и работи.
Какво точно се случва при тебе?

Пише

Proton IDE Setup
An error occured during the move data process: -132
Component:
File Group:
File:

Самият компилатор се инсталира. Пробвам да го натикам в MPLABa, ама и там е е една боза !

Идеален за кого? Сито е просто един масов език и това е основното му предимство.
Според мен никога не е бил идеален и в тоя си вид никога няма да стане. Това че аз, ти и още 100 милиона маймуни пишат на Си не го прави идеален, а само най-добър компромис.
Има много какво да се желае. Елементарен пример - не се използва рациално човешкия мозък. Всеки нормален човек има добре развита визуална памет. При някои хора (в това число и аз самият) визуалната памет и визуалното мислене е доста по-добре развито от останалото.
Тоя факт не се използва - не само от Ц ами и от почти всички езици за програмиране.
Няма да кометирам как би могло да стане това сега, но би могло да стане. Не вярвам да спориш че ако те накарат да откриеш 7-те разлики в две картинки ще ти е по-лесно да ги видиш визуално, отколкото като С-масив.
Проблемът не само на програмистите ами и на всички хора е че не използват мозъка си

Няма да коментирам различните дребни неща които куцат на Сито. Да има възможности да се "надгражда" и понякога се получават добри решения - съгласен съм. Примерно комбинация от Ц+ТСЛ, но не и както казваш да се ползва предпроцесор. Особено в ембедед приложения прекомерното използване на предпроцесора само създава проблеми. Навикът де се дефинират константи и функции с #define е вреден и побърква дебъгерите.
А същия ефект и код се постига ако константата си я обявиш с const и функцията си я направиш с inline - първо е по-чисто, второ по-сигурно и трето по-малко главоболия с дебъгера.

Темата е безкрайна, затова спирам....

Компилаторите на МикроЕлектроника никак не са лоши. Аз ползвам техния Паскал и съм супер доволен(платен). Иначе има чат пат и грешки(аз лично не съм откривал досега), но се оправят доста бързо от страна на Микроелектроника. Общо взето вече програмирам само на този компилатор.

Бейсикът им за ПИК18 има много сериозен недостатък. Разчитат за записа на W,STATUS,BSR при прекъсванията на shadow регистрите. Добре, ама сума ти 18-ки не записват правилно в тези регистри, бъгави та бъгави. С целия си акъл пратих до МЕ питане по въпроса, ама май само са го преместили в другия крачол.

Общо взето пиша на тоя компилатор от ver. 2.16 насам /някъде 2004 беше/ и няма нещо което да се е опряло включително FAT , LAN, us процеси и тнт. Кодът е съвместим с Delphi. Е има и някой дреболии, но лесно се хващат и могат да бъдат пренебрегнати, пък и микроЕ бързо ги оправят. Относно генерирания код - ами той много си зависи и от програмиста, аз съм доволен докарвам го средно до 3-4 байта на ред код. Библиотеките им не са за подценяване, а и много други хора пишат и споделят.

Сега само да Ви помоля да се въздържате от реплики "манете са от тука с тоз вашия паскал" - темата беше за отзиви от компилерите на микроЕ, не че не мога да пиша на С - мога ама не ме кефи и не виждам смисъла да се гърча. Като мина на платформа за която няма Pascal ше драскам на С.

Ако някой има питания по компилатора мога да му помогна.