Miért CCC?

Clipper, CCC

Egy nagyon tapasztalt C++ programozó feltette ma nekem a kérdést, hogy miért CCC? Miért létezik, miért használjuk, és milyen előnye van más nyelvekkel szemben?
Szedegessük össze a válaszokat, biztos, hogy nekem se jutott minden ott helyben eszembe, és ha esetleg valaki mástól is megkérdezik ezt, akkor ide lehet küldeni az illetőt.

w

  • 5427 megtekintés

( ffb | 2007. 01. 19., p – 16:09 )

rövid, áttekinthető kód;
könnyű karbantartani;
nyílt forrású, tehát idomítható;
könnyen tanulható;
a lefordított program gyorsasága;
eleget tesz a modern követelményeknek:
tárgyirányú,többszálúság,hálózati alkalmazások...

folytasd ....

képzavar, mit könnyű karbantartani, és minek nyílt forrású a kódja?
egyébként értem, a ccc programot és a ccc fordító.
de attól hogy nyílt forrású, azonkívül, hogy fordíthatsz magadnak fordítót miért lesz neked jobb?
mire gondoltál azzal, hogy 'idomítható'?

Nekem úgy tűnik, hogy mostanában a modern követelmények azt jelentik, hogy egy 4 emberhónapos egyszerű project-et simán el lehessen adni 40 emberhónapostként és lényegesen nagyobb hardverköltséggel (nagyobb haszon, több csúszópénz). Csakhát akkor valamit csinálni is kell, ezért jó, ha egy jó bonyolult n rétegű rendszert szállítanak, rengeteg géppel, minél átláthatatlanabbra tervezve, hogy a helyi rendszergazda még véletlenül se tudjon vele semmit kezdeni. Így a drága supportra is szükség lesz.
Olcsó programozót viszont nehéz találni, ezért célszerűen valami olyan nyelvet kell választani, amit a hátulgombolósok is tudnak használni.
Viszont aztán a hátulgombolósok miatt a rendszer még rosszabb lesz, mint tervezték és lehet, hogy még több hátulgombolós "programozót" vesznek fel, hogy ne csússzanak túl sokat a határidővel.

Nem tudom más hogy van vele, én már találkoztam egy-két ilyennel, mióta a szakmában vagyok (11 éve), de lehet, hogy rosszul látom a dolgokat.

( Wintermute | 2007. 01. 19., p – 19:04 )

Én azt látom, mondjuk szkeptikus szemszögből nézve, hogy a CCC sok szempontból emlékeztet a Pythonra. A Pythonban több a "gyári" library, de CCC-ből viszont elérhető az összes C++-os, amivel az ember azt éri el, hogy nem jön zavarba semmitől, például egzotikus adatbázis-kezelőktől (pl. Raima, való életből vett példa). Viszont a CCC kompilált, amit pont ma kifejezetten hátrányként hallottam, de szerintem előny. Ugyanis ha így odaadok valakinek egy programot, az fut, pont. Nem történik az meg vele, hogy egy váratlan rendszerfrissítés olyan API-változást von magával, amitől az interpretált nyelvek be szoktak dőlni (pl. XML::Parser változás Pythonban). Tudom, hogy lehet Python-t is fordítani bináris csomaggá, de erről még nem tudok többet, úgyhogy utánanézek.
Ezenfelül vannak olyan platformok, amikre nincs se Java, se Python, például ARM-os kis Linux disztribúciók, amikre az alternatíva az lenne, hogy C++-ban fejleszteni. Ugyanakkor a CCC-ben írott programok fordulnak rájuk, és nagyon kényelmes, hogy a megszokott és viszonylag ismert környezetet lehet használni. Tehát csatlakoznék mrev-hez: CCC-ben kódolni olyan, mintha megtartanám a C++ előnyeit, a hátrányai nélkül.
Még egy dolog: az ügyes kommunikáció és UI elválasztás. Konkrétan most az történt, hogy az egyik adatbázisos webes programon rengeteg editálnivaló támadt, és mostanáig úgy ment, hogy a Debianos szerveren futott egy xstart, és a felhasználók ráterminal-oztak, és szerkesztették az egyébként CGI-sen megjelenő adatbázist. Nagyjából 5 perc alatt le tudtam szedni a táblákat, és a helyi Windowsos gépen beüzemeltem ugyanazt a CGI+xstart környezetet, amit a szerveren, így most lokálisan megy az editálás. Ha megvan, akkor visszateszem a táblákat a szerverre, és a felhasználónak a terminál indító batch file-ját visszairányítom a szerverre. Ennyibe tart az, hogy lokális vagy távoli a környezet. Nem tudom, hogy mondjuk a Python tudja-e ezt, lehet, hogy igen.

w

Ugyanis ha így odaadok valakinek egy programot, az fut, pont. Nem történik az meg vele, hogy egy váratlan rendszerfrissítés olyan API-változást von magával, amitől az interpretált nyelvek be szoktak dőlni

Azzal viszont számolni kell, hogy az esetlegesen használt C++ könyvtárak API-ja megváltozik. Ekkor mindenképp ki kell adni egy új verziót.

Amúgy az intrepretált nyelvekben ritka az api váltás, pont azért, mert sokan nem törődnek a verzióval, csak azt teszik be a fejlécbe, hogy #!/usr/bin/perl és kész.

Kétségtelenül megtörténhet, hogy C++ API változik, és emiatt újat kell fordítani egy CCC-s programból. De azzal nem tudok egyetérteni, hogy az interpretált nyelvek API-ja ne változna gyakrabban, mint a C++ API, főleg, ha így általánosságban beszélünk, és belevesszük a Ruby-t is.
De ha már itt tartunk, nekem a szerveremen például a PHP-val rengeteg gondom volt már. Egyszer a phpBB hibáját kihasználva támadók jutottak shell-hez, szerencsére ennél messzebb már nem, de például amikor most nemrég a websvn-t telepítettem, akkor is gond volt azzal, hogy nem lehet secure mode-ban futtatni. De vegyük ezt a PHP kódot:

<?php
if (!isset($page))
{
$page = 'fooldal';
}
$page = "/".$page . '.php';
include "./" . $page;
?>

Ez a kód, bár látszólag teljesen jó, már nem futtatható secure módban. És nemigen kaptam hibaüzenetet sem, hanem egyszerűen csak nem volt értéke a $page-nek. Oké, tudom, hogy ez nem MINDEN interpretált nyelv sajátja, de hát ettől még a PHP nagyon is bennevan az interpretált nyelvek halmazában.
Na mindegy, eltértem a tárgytól, szóval szerintem azért mérhetően és érzékelhetően többet változik az interpretált nyelvek API-ja, mint a C++-os rendszerkönyvtáraké, és ráadásul ez nem az egyetlen dolog, meg nem is a legfontosabb.

w

Télleg nem akarok flame-elni, de hadd osszak meg egy linket, ami a Python helyzetéről szól: http://www.voidspace.org.uk/python/weblog/arch_d7_2007_01_27.shtml#e615
A cikk szerint van 5-féle versengő fő Python implementáció, meg még pár "futottak még" kategóriás. Kicsit kitér például arra is, hogy milyen átállási nehézségek lesznek a 2.6-osról a 3-as Pythonra.

w

Ugyanezek a hibák a Clipper/CCC/Clip-et is sujtanák, csak ezeknek nincs észrevehető mennyiségű felhasználója.

A Clipper sokkal régebbi, mint a Python, emiatt vannak olyan kellemetlen öröségek, amiket nem lehet visszamenőleg kijavítani. Ilyen, hogy régen nem voltak névterek, azért a globális névtér meglehetősen szennyezett. Nem tudom, van-e a Clipben névtér, ha van is, biztosan másképp van, mint a CCC-ben. Az osztályok is másképp vannak, stb. Nincs is igény az egységesítésre, ami egyébként reménytelen volna.

Szerintem a CCC azzal tűnik ki a rokonai közül (beleértve a CPythont), hogy a legegyszerűbben épül rá a C infrastruktúrára. Ezért nem erőlködöm, hogy legyen CCC .NET-re, JVM-re (noha gondoltam rá).

Ránéztem a python.org-ra, de hirtelenjében nem találtam infót a Python 3 változásairól. Nem tudsz egy ilyen linket?

--
CCC3

Megtaláltam a Python 3 áttekintő ismertetését Wikipedián, és mint ahogy sejtettem, ők is rájöttek, hogy a stringeket unicode-ként kell kezelni, és kell egy külön típus a bytesorozatokhoz:

"unifying the str/unicode types, and introducing a separate mutable bytes type"

Ebben sikerült kicsit megelőzni a Pythont, mint ahogy szó van róla itt: CCC3 unicode.

--
CCC3

( mrev | 2007. 01. 20., szo – 12:16 )

Az embereket nem lehet egyenként rábeszélni a CCC-re, hogy az milyen fasza dolog. Nem is cél, aki tudja, tudja. Végképp nincs értelme arról vitázni, hogy mi a korszerű. A C/C++ pl. nem korszerű. Mégsem lehet nélkülözni a C-t, mert ezen alapul az informatikai univerzum. Azért csak annyit mondok: azért jó a CCC, mert praktikus és jól illeszkedik az informatikai univerzumba.

--
CCC3