Gå till innehåll
Just nu i M3-nätverket

Carbon eller Cocoa


jens_rock

Rekommendera Poster

Nja, i de senaste mätningarna jag såg var både Java och C mer populära än C++.

Hos arbetsgivare? Eller anställda? Eller hemmapulare? Eller på universiteten? Eller...

Länk till kommentar
Dela på andra webbplatser

Lars Torpare
Hos arbetsgivare? Eller anställda? Eller hemmapulare? Eller på universiteten? Eller...

Hos alla. Programmering är programmering oavsett var den utövas.

Länk till kommentar
Dela på andra webbplatser

Hos alla. Programmering är programmering oavsett var den utövas.
Jo, men arbetsgivare har ofta en annan åsikt en de utvecklare som gör arbetet…
Länk till kommentar
Dela på andra webbplatser

Hos alla.

Det tror jag inte på.

 

Vad arbetsgivare vill ha är inte säkert att någon helst vill jobba med. Jag såg två olika platsannonser för bara några månader sedan. Ett företag ville ha Fortran-programmerare och ett annat COBOL-programmerare. Inte särskilt kul språk något av dem.

 

På universiteten kanske det sker undervisning i språk som inte är särskilt gångbara på arbetsmarknaden, eller som studenterna inte tycker är "häftiga" nog (eller båda!).

 

Så, var kan man läsa om undersökningen? Dvs, vilka som frågades, hur frågan ställdes, osv

Länk till kommentar
Dela på andra webbplatser

Lars Torpare

Jag tänkte mest på t ex Tiobe som brukar ge en rätt bra bild av vad som är populärt. Även om den har en del brister har jag aldrig sett en bättre undersökning som dessutom hålls aktuell.

Länk till kommentar
Dela på andra webbplatser

Jag tänkte mest på t ex Tiobe som brukar ge en rätt bra bild av vad som är populärt. Även om den har en del brister har jag aldrig sett en bättre undersökning som dessutom hålls aktuell.

Ja, inte frågar jag efter C++ när jag frågar (exempelvis) Google om hur man använder ett API. Detta trots att jag jobbar uteslutande med C++. Och hur man använder ett API är nästan det enda jag frågar efter när det gäller programmering.

Länk till kommentar
Dela på andra webbplatser

Jag tror det beror på hur man tolkar populärare, C++ är förmodligen det mest använda "OO" språket som finns, jag vet många som jobbar med det men få som faktiskt tycker det är ett bra språk.

Personligen gillar jag vissa delar av C++, och syntaxt mässigt tilltalar det mig mer än Objective-C; Jag har alltid gillat pekare och statiskt kompilerade språk, Java, Objective-C osv ger inte riktigt samma möjligheter på det området om man ska skriva som det är "tänkt".

 

Däremot dras C++ med många problem som gör det direkt olämpligt för mycket; Att Apple valde att göra IOKit i (visserligen förenklad C++) är för mig lite konstigt då det är ett språk som är ganska olämpligt för allt vad heter kompabilitet överhuvudtaget, Be hade enorma problem med C++ med sitt BeOS vilket gjorde både API och underhåll ett jobbigt tankearbete. FBC problemet är inte att underskatta men det är ju möjligt att fightas runt det men som sagt varför välja ett språk som har det problemet till sådana saker?

Svaret är rätt enkelt egentligen, det enda OO språket som har dom fördelar som krävs på låg nivå, statisk kompilering (snabb objektkod), relativt lättöverskådlig kod.

 

Men kortfattat tror jag det Lars menade med populära språk var "mest omtyckta språk" inte "mest använda språk"

 

---

 

(Och med statiskt kompilerade menar jag snarare "statiskt länkade" än "nativa vs bytekod")

Länk till kommentar
Dela på andra webbplatser

Ingemar Ragnemalm
Vad arbetsgivare vill ha är inte säkert att någon helst vill jobba med. Jag såg två olika platsannonser för bara några månader sedan. Ett företag ville ha Fortran-programmerare och ett annat COBOL-programmerare. Inte särskilt kul språk något av dem.

 

På universiteten kanske det sker undervisning i språk som inte är särskilt gångbara på arbetsmarknaden, eller som studenterna inte tycker är "häftiga" nog (eller båda!).

Skulle vara LISP eller MatLab då. Annars har universiteten nästan totalt förlorat integriteten att undervisa de språk som är intressantast eller bäst att jobba med, utan undervisar nästan bara det industrin vill ha, vilket ger flata och ointressanta ingenjörer som inte har något perspektiv. Den som bara kan C++ vill jobba med C++ även om det varken är det bästa för uppgiften eller personen.

 

Jag är själv medskyldig. Hade jag lite råg i ryggen skulle jag sätta studenterna på att använda något jag själv tror på. I stället kör vi C/C++, för böckerna är skrivna för det och alla kan det mer eller mindre. Vi har kört en del Java också, samma skit det också, risigt industrispråk med dålig syntax. Men jag har inte orkat ta striden att köra med ett snyggare språk och kämpa med en massa gnällspikar som inte kan se bortom fiskmåsarna. Följden är förstås att jag inte bidrar till att lära dem att det finns alternativa vägar. (Å tredje sidan vet jag att jag dessutom skulle få slåss med supporten som skulle vägra installera de verktyg jag skulle behöva, så det finns mer skäl till att man inte orkar.)

 

En av mina bästa studenter fick jobb som Cobol-programmerare hörde jag. Jag tänkte att han lätt skulle kunna få andra jobb, men om han gillar det så är det ju inget problem. Och så himla illa var inte Cobol som jag minns det. (Fast jag har inte rört det sedan jag var student.)

Länk till kommentar
Dela på andra webbplatser

Ingemar Ragnemalm

Just det, nu kom jag på vad jag skulle fråga i den här tråden:

 

Alla som satsat på Cocoa brukar hävda att det är så kraftfullt och produktivt. Jag hör ju vad de säger men ser aldrig någon substans bakom det. Nu tycker jag helt allvarligt att mycket av Carbons nya delar är mer än lovligt snåriga jämfört med det gamla, anropen är bökigare och det krävs mycket mer kod för att göra allting (utom trivialiteter som nästan inte kräver någon kod alls). Men sånt brukar man koda sig runt genom att bygga någon smart ramverk. Det hade jag redan i Classic, så det är bara att göra nåt liknande nu (håller redan på och har kommit en bra bit), med lite nya delar för nya dialogelement och sånt.

 

Men finns det något alldeles tydligt extra smart med Cocoa/ObjC? Det jag hör mellan raderna är "jag har lärt mig det och det funkar så då är det perfekt" och "Apple säger gå i takt så då gör jag väl det då". Jag skulle vilja höra nåt som är aningen mer övertygande.

Länk till kommentar
Dela på andra webbplatser

Men jag har inte orkat ta striden att köra med ett snyggare språk och kämpa med en massa gnällspikar som inte kan se bortom fiskmåsarna.

 

Just det, nu kom jag på vad jag skulle fråga i den här tråden: (...)

 

Men finns det något alldeles tydligt extra smart med Cocoa/ObjC? (...) Jag skulle vilja höra nåt som är aningen mer övertygande.

 

Övertygande vet jag inte, och helt utan argument för det eventuellt produktiva, men... Cocoa/ObjC, är som jag ser det, Smalltalk med C-syntax. Och Smalltalk, i mina ögon, är som programmeringsmiljö otroligt vackert.

 

Designen och arkitekturen bakom Cocoa är fullkomligt briljant. Enkel och kraftfull. Användning av designmönster som det skall göras. Ta till exempel NSNotification (en implementation av designmönstret Observer) som ger möjlighet att skicka och ta emot meddelanden, utan att sändare och mottagare behöver känna till varandra. Det behöver inte vara svårare än så: ett enkelt interface (NSNotification) som kapslar in ett meddelande plus en meddelandecentral (NSNotificationCenter). "Keep it simple".

 

 

Kommentarer? Frågor? Physical abuse?

Länk till kommentar
Dela på andra webbplatser

Alla som satsat på Cocoa brukar hävda att det är så kraftfullt och produktivt. Jag hör ju vad de säger men ser aldrig någon substans bakom det.

Vad menar du ingen substans bakom det?

Har du överhuvudtaget använt Cocoa så borde du märkt att det tar en fjärdedel av produktionstiden att skriva ett program i cocoa mot carbon, detta för att cocoa automatiskt implementerar väldigt mycket; att mycket kommer gratis genom att använda cocoa, man behöver aldrig bry sig om cutnpaste, dragndrop osv i någon större utsträckning det bara fungerar. serialization osv gör det rent av sagt skitsmidigt att spara dokument eller skriva multimaskinprogram osv.

Självklart finns det frameworks för Carbon också som jag mycket väl vet att du vet om redan, PowerPlant; TCL; MacApp osv, Men dom kan inte på långa vägar mäta sig med Cocoa, dom har helt enkelt inte språket för sig; Det är därför Objective-C är det självklara valet när man jobbar med Cocoa det är dessflexibilitet som gör Cocoa så lysande.

 

Nu tycker jag helt allvarligt att mycket av Carbons nya delar är mer än lovligt snåriga jämfört med det gamla, anropen är bökigare och det krävs mycket mer kod för att göra allting (utom trivialiteter som nästan inte kräver någon kod alls). Men sånt brukar man koda sig runt genom att bygga någon smart ramverk. Det hade jag redan i Classic, så det är bara att göra nåt liknande nu (håller redan på och har kommit en bra bit), med lite nya delar för nya dialogelement och sånt.

Och återigen Cocoa är bara ett framework (ramverk) skrivet i Objective-C varför återuppfinna hjulet när man har tillgång till ett framework som har över ett decennium av tester och program bakom sig?

 

Men finns det något alldeles tydligt extra smart med Cocoa/ObjC? Det jag hör mellan raderna är "jag har lärt mig det och det funkar så då är det perfekt" och "Apple säger gå i takt så då gör jag väl det då". Jag skulle vilja höra nåt som är aningen mer övertygande.

 

Ja flexibilitet, Men det är inget som man kan förklara för någon som inte vill lyssna.

Du gör dig själv en stor tjänst om du ger cocoa en chans i någon eller några dagar- Det är inte Macintosh Toolbox så förvänta dig inte att det har exakt samma omfång, men för GUI apps så är det helt klart överlägset allt annat som finns på marknaden.

Länk till kommentar
Dela på andra webbplatser

Tobberoth
Personligen gillar jag vissa delar av C++, och syntaxt mässigt tilltalar det mig mer än Objective-C; Jag har alltid gillat pekare och statiskt kompilerade språk, Java, Objective-C osv ger inte riktigt samma möjligheter på det området om man ska skriva som det är "tänkt".

 

Är rätt säker på att Objective-C har både pekare (det är jag hundra på) och är statiskt kompilerat. Objective-C är bara ett mycket snyggare och mer funktionellt subspråk till C, det mesta som gäller C gäller ju objective-C.

Länk till kommentar
Dela på andra webbplatser

Ingemar Ragnemalm
Vad menar du ingen substans bakom det?

Inga begripliga exempel, typfall, bara en massa tomsnack om "vackert" och "produktivt". Substanslöst.

Har du överhuvudtaget använt Cocoa så borde du märkt att det tar en fjärdedel av produktionstiden att skriva ett program i cocoa mot carbon, detta för att cocoa automatiskt implementerar väldigt mycket; att mycket kommer gratis genom att använda cocoa, man behöver aldrig bry sig om cutnpaste, dragndrop osv i någon större utsträckning det bara fungerar.

Jämfört med vad? Det behövs två program med samma funktionalitet bredvid varandra för att kunna dra några slutsatser.

serialization osv gör det rent av sagt skitsmidigt att spara dokument eller skriva multimaskinprogram osv.

Självklart finns det frameworks för Carbon också som jag mycket väl vet att du vet om redan, PowerPlant; TCL; MacApp osv,

De flesta av de du nämner är gamla "Toolbox"-frameworks, i den mån de finns för Carbon så är det "classic Carbon". TCL finns i Carbon-version, men det var ingen ambitiös portning.

Men dom kan inte på långa vägar mäta sig med Cocoa, dom har helt enkelt inte språket för sig; Det är därför Objective-C är det självklara valet när man jobbar med Cocoa det är dessflexibilitet som gör Cocoa så lysande.

Och återigen Cocoa är bara ett framework (ramverk) skrivet i Objective-C varför återuppfinna hjulet när man har tillgång till ett framework som har över ett decennium av tester och program bakom sig?

För att man lika gärna kan porta ett bra ramverk som har TVÅ decennier bakom sig, och få ett gränssnitt som är lika bra men låter en använda bättre språk än Objective C och som gör att hundratusen rader gammal kod inte måste skrivas om från grunden?

Ja flexibilitet, Men det är inget som man kan förklara för någon som inte vill lyssna.

Jag har lyssnat på en massa folk som alla säger "flexibilitet" och "vackert" men inte ett skit mer, och alla vägrar säga mer. Det tycker jag är oroväckande. Om man inte jämför någonting konkret så är det bara "titta det funkar" och "jag kan det här". Det betyder ingenting alls.

 

Enkelhet, mycket som är gratis? Tja, triviala Carbon-tillämpningar är bara en halv sida kod, och så görs resten med defaulthandlers. Det "bara funkar", men är helt ointressant. Det som är intressant är vad som händer när man gör något annat.

Länk till kommentar
Dela på andra webbplatser

thobbe och ingemar jag har läst era poster men har inte möjlighet att svara än, men för thobbes del rekommenderar jag att han läser om min post inklusive editeringen jag gjorde kort efter den postats.

Länk till kommentar
Dela på andra webbplatser

Är rätt säker på att Objective-C har både pekare (det är jag hundra på) och är statiskt kompilerat. Objective-C är bara ett mycket snyggare och mer funktionellt subspråk till C, det mesta som gäller C gäller ju objective-C.

 

Så nu har jag tid.

 

ObjC har pekare iform av "id" samt standard C pekare (tackvare dess C bakåtkompabilitet) men det jag syftade på var att kunna skapa en pekare som pekar på en klass eller valfri data vilket kan vara användbart i länkade listor osv, men visst det är möjligt att skapa i Objective-C (även om det inte egentligen är "ObjC" utan vanlig C och lite hackande) det var främst javas brist på pekare jag tänkte på.

 

Med statiskt kompilerat (ja det var ett dåligt uttryck men jag fann inte korrekt ord vid tillfället jag skrev inlägget, jag försökte korrigera detta genom att helt enkelt skriva att det var statisk länkning jag menade; men det är heller inte korrekt egentligen) det jag menade var att i C++ binds symboler till en address permanent när man kompilerar, Objective-C måste kolla upp addressen för samtliga objekt man använder detta har för och nackdelar; största fördelen är att man helt och hållet kommer runt FBC problemet, största nackdelen är att det tar längre tid och gör det väldigt svårt att skriva lågnivåkod med språket.

 

C++ kan "resolva" dynamiskt genom RTTI men det är varken snyggt eller speciellt smidigt för det mesta; personligen gillar jag statisk bindning mer efter som det ger mig som programmerare större kontroll över programmet och låter mig utnyttja vissa givna faktum så som att jag kan räkna ut hur långtid metodsanroppet kommer ta vilket iprincip är omöjligt i Objective-C men det går naturligtvis räkna på värsta falls scenario vilket däremot är väldigt opraktiskt rent praktiskt då i värsta fall ett metodsanrop kan ta över 200+ cykler medans ett C++ anrop garanterat max tar runt 8-10 cykler. För vardags program har det ingen större betydelse, skriver man kod som kräver snabb och förutsägbar respons (diverse realtime system- försök skriva ett program som får en robot att balansera i Objective-C och du förstår ganska snabbt vikten av förutsägbara svarstider)

Varje språk har sina för och nackdelar; Och det var just vad jag försökte säga i mitt tidigare inlägg.

Länk till kommentar
Dela på andra webbplatser

Inga begripliga exempel, typfall, bara en massa tomsnack om "vackert" och "produktivt". Substanslöst.

Vad som är vackert är upp till användaren att avgöra så där kan jag hålla med om att det är sbustanslöst.

Men att Cocoa inte skulle vara produktivt anser jag är väldigt bevisat; Att jämföra cocoa och powerplant är som att jämföra applescript studio och visualbasic, Cocoa är så nära RAD man kommer utan att ta bort kontrollen från programmeraren. Det är EXTREMT snabbt att jobba med när man lärt sig grunderna; har man aldrig skrivit ett toolbox program så lär man inte skriva sitt första carbon program under den tiden man hunnit utveckla program som håller väldigt hög kvalite.

 

Jämfört med vad? Det behövs två program med samma funktionalitet bredvid varandra för att kunna dra några slutsatser.

Jag har hållt på med ganska många frameworks under åren, på Macintosh sidan framförallt PowerPlant, (aningen MacApp) och riktigt långt tillbaka macskel (vilket iofs inte spelar i samma division) och det finns helt enkelt inget som mäter sig med Cocoa, det närmsta är nog PowerPlant men det är oerhört bökigt att hålla på med ijämförelse.

 

De flesta av de du nämner är gamla "Toolbox"-frameworks, i den mån de finns för Carbon så är det "classic Carbon". TCL finns i Carbon-version, men det var ingen ambitiös portning.

För mig veterligen är finns det inga frameworks som spelar i samma division som ovannämnda skrivna för HIToolbox och co.

 

För att man lika gärna kan porta ett bra ramverk som har TVÅ decennier bakom sig, och få ett gränssnitt som är lika bra men låter en använda bättre språk än Objective C och som gör att hundratusen rader gammal kod inte måste skrivas om från grunden?

Men Cocoa är inte portat! Cocoa är ett framework skrivet i ObjectiveC därför anropas det i ObjectiveC, Apple gjorde Carbon överhuvudtaget för att just ge utvecklare tid att _skriva om_ sina projekt, Carbon är här för att stanna men apple har gjort det väldigt klart att det är Cocoa som gäller och som kommer vara prioritet, Poängen med Cocoa är inte att man ska skriva hela program i det, Man skriver frontends; en frontend får man porta oavsett vilket API som används, skriver man på det sättet ger inte cocoa något speciellt "overhead".

Microsoft håller på att flytta över helt och hållet till .net, Apple flyttar över mer och mer mot ObjectiveC. Det är bara att acceptera, Jag förstår din frustration som krossplatforms utvecklare, Jag har själv hållt på med det och det är ett jäkla skit om man vill ha det enkelt för sig, Men samtidigt resonerar jag att man ska lägga lika mycket tid på samtliga portar för det är användar upplevelsen som är viktigast och man kan aldrig få en bra upplevelse om man inte tar sig tid och polerar på det hela.

 

Jag har lyssnat på en massa folk som alla säger "flexibilitet" och "vackert" men inte ett skit mer, och alla vägrar säga mer. Det tycker jag är oroväckande. Om man inte jämför någonting konkret så är det bara "titta det funkar" och "jag kan det här". Det betyder ingenting alls.

hur förklarar man flexibelt för någon som är så rädd att prova? ungefär som att säg förklara böjbart för en blind? jag vet inte tyvärr ingemar, jag kan inte förklara det det är något man måste uppleva och se relationen mellan allt själv. det är ObjectiveC som gör det hela flexibelt inte Cocoa i sig även om Cocoa utnyttjar just den egenskapen av ObjectiveC.

 

Enkelhet, mycket som är gratis? Tja, triviala Carbon-tillämpningar är bara en halv sida kod, och så görs resten med defaulthandlers. Det "bara funkar", men är helt ointressant. Det som är intressant är vad som händer när man gör något annat.

Likvärdiga enkla Cocoa program är 0 sidor kod, betydligt mer avancerade Cocoa program är alltid eller nära på identiska Carbon program kod mässigt, men jag har aldrig stött på någotfall där ett Cocoa program varit större.

Länk till kommentar
Dela på andra webbplatser

Ingemar Ragnemalm
hur förklarar man flexibelt för någon som är så rädd att prova?

Rädd för att prova??? Här betyder "prova" att lägga ett par månader på att plöja en eller ett par böcker och sätta sig in i ett språk och ett större OO-ramverk på samma gång. Det är tamejtusan inget att ta lättvindigt! Jag försöker hitta en punkt - frågar aktivt efter den - där "prova" inte betyder en effektiv kostnad på några hundra tusen kronor, och du kallar mig "rädd för att prova"! :chockadskeptisk:

Länk till kommentar
Dela på andra webbplatser

Rädd för att prova??? Här betyder "prova" att lägga ett par månader på att plöja en eller ett par böcker och sätta sig in i ett språk och ett större OO-ramverk på samma gång. Det är tamejtusan inget att ta lättvindigt! Jag försöker hitta en punkt - frågar aktivt efter den - där "prova" inte betyder en effektiv kostnad på några hundra tusen kronor, och du kallar mig "rädd för att prova"! :chockadskeptisk:
I så fall är det väl inte stor poäng att argumentera mot något som man inte ändå inte kan eller vill prova på? Kanske bättre och säga kan väl vara bra men jag har verken tid eller lust att prova… Jag bara undrar. (Du behöver ju inte bemästra språket bara för att känna på det lite, eller?)
Länk till kommentar
Dela på andra webbplatser

Lars Torpare
Jag har lyssnat på en massa folk som alla säger "flexibilitet" och "vackert" men inte ett skit mer, och alla vägrar säga mer. Det tycker jag är oroväckande. Om man inte jämför någonting konkret så är det bara "titta det funkar" och "jag kan det här". Det betyder ingenting alls.

Surfa runt lite på Cocoa Dev Central så ska du nog hitta bra exempel.

 

En av mina största favoritexempel på hur enkelt det är att arbeta med Objective-C. Vilken av dessa kodexempel har du lättast att förstå innebörden av utan att behöva kolla upp dokumentationen?

 

[NSApp beginSheet:speedWindow
  modalForWindow:[inLetterView window]
modalDelegate:self 
  didEndSelector:@selector(sheedDidEnd:returnCode:contextInfo:)
  contextInfo:NULL];

 

NSApp.beginSheet(speedWindow, inLetterView.window, self, @selector(sheedDidEnd:returnCode:contextInfo:), NULL);

Länk till kommentar
Dela på andra webbplatser

I så fall är det väl inte stor poäng att argumentera mot något som man inte ändå inte kan eller vill prova på? Kanske bättre och säga kan väl vara bra men jag har verken tid eller lust att prova… Jag bara undrar. (Du behöver ju inte bemästra språket bara för att känna på det lite, eller?)

Men Ingemar argumenterar inte emot. Han (och jag) vill ha något konkret som skulle kunna motivera en seriös investering av tid.

Länk till kommentar
Dela på andra webbplatser

Vi har heller inte betalt för att övertyga er att ge Cocoa en chans, ärligt talat så rör det mig inte speciellt mycket vare sig ni använder det eller inte det är erat val och eran förlust att inte använda det.

Jag hävdar fortfarande att det är svårt att förklara vad som gör Cocoa så bra utan att ha provat det, det är ett framework som tar några dagar att sätta sig in i, månader är våldsamt överdrivet- speciellt om man hållt på med frameworks tidigare.

Men kortfattat på den energi ni lagt på inlägg i den här diskussionen hade ni lätt gjort både 2-3 cocoa program som varit en bra demostration om fördelarna med det verktyget.

Ingen har någonsin sagt att Cocoa är det ultimata svaret på alla problem, det är det inte men det är ett väldigt bra universellt svar.

 

Men kortfattat jag har inget yttligare att tillägga i diskussionen, inte förrän jag kan sitta här på arbetstid och inte behöva betala med min fritid för att utvärdera och betygsätta verktyg åt andra så dom kan spara pengar. Jag har sagt vad jag tycker och försökt förklara ut ifrån ett vänligt perspektiv mer energi än så här lägger jag inte på den här debatten.

Länk till kommentar
Dela på andra webbplatser

Jag har en del erfarenhet av de olika miljöerna. Ett av mina program, Ordboken, var först skrivet för OS 7 i pascal, därefter i Carboniserad c++ och slutligen i Cocoa och objektive-C. Efter den sista omskrivningen till Cocoa var antalet kodrader bara tredjedelen mot för innan, samtidigt som programmet hade större funktionalitet.

 

Jag upplevde det som ett lyft att programmera i Obj-C i jämförelse mot för c++, och ännu bättre blir det nu när Obj-C äntligen får garbage collection. Carbon var bra för att snabbt komma över till OS X men det finns ingen orsak att starta nya projekt i den miljön om det inte vore för att man ibland måste använda den för vissa mer os-nära uppgifter. I Ordboken rör det sig om ca 200 rader Carbon som främst har att göra med att hämta vad som är selekterat i andra program.

Länk till kommentar
Dela på andra webbplatser

Arkiverat

Det här ämnet är nu arkiverat och är stängt för ytterligare svar.



×
×
  • Skapa nytt...