Of course, there are many plusses with going with English. Firstly, programming language syntax is usually written in English. If one writes own code in another language, the code is bilingual. I’m not an expert in psychology but I think it is safe to say that reading bilingual code adds at least some burden to the programmer’s mental burden.

Another obvious plus is that English is de facto language of the programming world so if you’re collaborating with programmers speaking another language, you are more likely to have English than anything else as your common language. This is also fairly safe bet for the customer or managers of the project. If the project is written in English, it is easier to move development to another company or country. This can of course be exploited by a programmer: writing in non-English language can be used as a guarantee that one will not be kicked out of the project as easily. Hopefully a programmer doesn’t need this kind of shenanigan and can prove one’s worth with technical prowess rather than knowing an obscure natural language.

These are pretty weighty reasons for using English so what are the pluses for using something else?

Unfortunately, even though English is de facto language in programming world, that doesn’t necessarily mean that all programmers can use English proficiently. Maybe they’ve learned to program in a non-English-speaking school or reading non-English books. They might be sufficient enough to understand error messages or other such short messages. However, writing unambiguous and comprehensive documentation for quite abstract constructs such as an architecture of multithreaded banking application requires a lot of talent. Usually programmers struggle even with writing this kind of documentation in their native tongue without the additional burden of using another language.

I think that it’s very important to use good naming when writing a software. If for example the models of the software are named well, it is much easier to understand the software firstly as a developer but also as an user. Figuring out good names is hard: figuring out good names in multiple languages is more than twice as hard. This can create a barrier between the developers and customers or project managers. If managers and customers tend to use for example Finnish terms for business models, developers mentally translate these terms to their English counterparts before processing the message of the customer. If names are poorly selected or in a worst case, there are multiple ambiguous translations, it’s a lot harder to be on the same page about the current state and the future of the project.

Next time when you’re starting a new project, please take a moment to think if English is really the best choice for writing your program in. If this decision is done in haste, it is very time consuming to translate the code later on if the decision proves to wrong.

Analyysini tavoitteena on tutkia ohjelmistoalaan erikoistunutta Y Combinator -yrityshautomoa ja analysoida muun muassa sen perustajien, sijainnin ja siihen valittavien startup-yritysten toimialan merkitystä yrityshautomon menestykselle sekä yleisesti markkinoille.

Mikä Y Combinator?

Y Combinator on vuonna 2005 perustettu yrityshautomo. Y Combinator valitsee kahdesti vuodessa suuren joukon ohjelmistoalan startup-yrityksiä (n. 60), joita he rahoittavat suhteellisen pienellä summalla (keskimäärin 18 000 dollaria). Vuodesta 2005 toiminut Y Combinator on rahoittanut 300 yritystä. [1]

Yksi Y Combinatorin perustajista, Paul Graham, on kokenut startup-yrittäjä. Vuonna 1995 hän perusti Viaweb-yrityksen, joka tarjosi asiakasyrityksille web-sovelluksen, joilla he voivat rakentaa omia verkkokauppojaan. Viaweb oli pieni yritys, mutta pienen kokonsa ansiosta ja valitsemalla tehokkaat työkalut ohjelmistonsa toteuttamiseen Viaweb pystyi nopeasti reagoimaan isojen kilpailijoidensa uusiin ominaisuuksiin. [2] Vain kolme vuotta yrityksen perustamisen jälkeen Viawebin omistajat myivät yrityksen Yahoolle 49 miljoonalla dollarilla. [3]

Sama asenne näkyy myös Y Combinatorin koulutusohjelmassa, jossa käytetään usein käsitettä “ramen profitable”. Ramen profitable tarkoittaa, että startup on sen verran kannattava, että sen nuoret perustajat pystyvät juuri elättämään itsensä ja pyörittämään yritystään. Ramen-sana viittaa edulliseen japanilaiseen ateriaan. Ramen profitable -tason yritys ei olisi mahdollinen esimerkiksi tietokonevalmistajana, koska tietokoneen valmistaminen vaatii mittavia panostuksia muun muassa tehtaisiin ja niiden työntekijöihin ennen kuin lopullinen tuote on mahdollista valmistaa. Y Combinatorin valitsemat yritykset ovat ohjelmistoalan yrityksiä, jotka eivät vaadi parhaassa tapauksessa muuta kuin työntekijöilleen tietokoneet, jotka todennäköisesti löytyvät jo omasta takaa. Grahamin mukaan ramen profitable -ajattelussa on useita hyviä puolia: Ensinnäkin yritys pystyy toimimaan ilman rahoittajien metsästämistä ja heidän kanssa neuvottelua. Tämä ei tarkoita sitä, etteikö yritys pyrkisi saamaan ollenkaan rahoitusta, vaan että heidän ei ole sillä hetkellä ehdottoman pakko keskittyä sen hankkimiseen. Toinen hyvä puoli on yrityksen moraalin kehittäminen, koska vastaperustettu yritys saattaa tuntua teoreettiselta, mutta oikeiden asiakkaiden ja kassavirtojen saaminen auttaa sen konkretisoimisessa. Kolmantena yritys pääsee laittamaan liikeideansa ikään kuin julkiseen beta-vaiheeseen, joka paljastaa liikeidean hyvät ja huonot puolet. [5]

Y Combinator ei ole pelkästään Grahamin kädenjälkeä. Esimerkiksi Paul Grahamin vaimo, Jessica Livingston toimi ennen Y Combinatoria markkinoinnin varajohtajana Adams Harkness -investointipankissa ja kirjoitti yritysten perustajista haastattelukirjan, Founders at Work. [22] Livingston haastatteli kirjaansa varten muun muassa Adoben, Applen, Fog Creek Softwaren, Paypalin, Research In Motionin ja Yahoo!:n perustajia. [23]

Lisäksi Y Combinatoriin kuuluvat osakkaina

• Trevor Blackwell – Anybotsin perustaja, PhD-tutkinto tietotekniikasta Harvardista,
• Paul Buchheit – Gmailin perustaja, rakensi prototyypin Googlen AdSense-mainospalvelusta ja kehitti Googlen sloganin “Don’t be evil”,
• Robert Morris – Morris-madon kirjoittaja, tietotekniikan professori MIT:llä, PhD-tutkinto tietotekniikasta Harvardista, ja
• Harj Taggar – Auctomaticin perustaja, joka opiskeli lakia Oxfordin yliopistossa. [22]

Y Combinatorin osakkaiden laaja ammattitaito ja kattavat verkostot ovat merkittävä etu Y Combinatorin hautomoyrityksiä auttaessa. Liian usein tekniikan alan ihmiset keskittyvät liikaa vain tekniikkaansa ja unohtavat esimerkiksi henkilöstöjohtamisen ja markkinoinnin tärkeyden.

Sijainnin merkitys

Yksi ilmeinen selitys Y Combinatorin sijaitsemiselle Yhdysvalloissa lienee se, että Y Combinatorin perustajat asuivat Yhdysvalloissa. Tämä ei kuitenkaan selitä sitä, miksi sijaitseminen Yhdysvalloissa on todennäköisesti paras valinta.

Eräs suurista hyvistä puolista Yhdysvalloissa on suuret sisämarkkinat. Esimerkiksi Euroopan unionissa on 500 miljoonaa asukasta, mutta Euroopan union sisällä on kuitenkin suuria kulttuuri- ja kielieroja maiden välillä. Lisäksi maiden sisäinen lainsäädäntö vaihtelee suhteellisen paljon. Yhdysvaltojen kaikki 50 osavaltiota käyttävät pääsääntöisesti samanlaista lainsäädäntöä pienillä osavaltiokohtaisilla eroilla ja kaikkien virallinen kieli on englanti. Myös espanjaa äidinkielenään puhuvien määrä on kasvussa, mutta vaikka espanjakin valittaisiin yrityksen käyttämäksi kieleksi englannin lisäksi, olisi kielten määrä kuitenkin vain kaksi. Sen sijaan EU:ssa on 23 eri virallista kieltä [24] ja lisäksi monta epävirallista.

Kiina voisi olla toinen hyvä sijainti vastaavalle yrityshautomolle, mutta ainakin toistaiseksi Kiinan kaupankäynti on kohdistunut enemmän ulkomaille kuin sen omille sisämarkkinoille. Lisäksi suurin osa maan väestöstä on köyhää, joten korkean teknologian ohjelmistopalveluita tarjoaville yrityksille ei ole vielä yhtä hedelmällistä maaperää.

Paul Graham listaa esseessään Why Startups Condense In America 10 syytä, miksi hänen mielestään Yhdysvallat on paikka, johon Piilaakso on ollut mahdollista rakentaa:

1. Yhdysvallat sallii maahanmuuton. Piilaakso tarvitsee älykkäitä ihmisiä, joiden pääsyä sinne ei sovi estää.
2. Yhdysvallat on rikas valtio. Rikkaalla valtiolla on kehittyneempi infrastruktuuri, jossa yritykset voivat kukoistaa.
3. Yhdysvallat ei ole (vielä) poliisivaltio. Jos esimerkiksi poliitikasta ei ole sallittua ajatella uusilla radikaaleilla tavoilla, miten ihmiset pystyvät luomaan uusia radikaaleja bisnesideoitakaan?
4. Yhdysvalloissa on paljon hyviä yliopistoja. Etenkin tekniikan alan parhaat yliopistot löytyvät pääasiassa Yhdysvalloista.
5. Yhdysvalloissa on helppo erottaa ihmisiä, jos he osoittautuvat epäpäteviksi.
6. Yhdysvalloissa ei suhtauduta työhön enää niin, että työ on jotain, jota saadaan, vaan se voi myöskin olla jotain, jonka itse luo.
7. Yhdysvalloissa on helppo perustaa yritys, koska lainsäädäntö ei ole niin tiukkaa kuin monessa muussa valtiossa.
8. Yhdysvalloissa on suuret sisämarkkinat.
9. Yhdysvalloista löytyy paljon rahoittajia.
10. Yhdysvalloissa työurat ovat dynaamisempia eivätkä ihmiset yleensä joudu valitsemaan omaa uraansa jo lukioiässä. [25]

Entä sitten Y Combinatorin sijainti Yhdysvaltojen sisällä? Alunperin Y Combinatorin kesäkausi järjestettiin Cambridgessä, Massachusettsissa ja talvikausi Mountain View’ssa, Kaliforniassa, mutta vuonna 2009 Paul Grahamin sekä hänen vaimonsa ja toisen Y Combinatorin Jessica Livingstonen perhesyistä johtuen kesäkaudetkin päätettiin järjestää Mountain View’ssa. [6]

Mountain View sijaitsee Piilaaksossa, joka taas sijaitsee Kaliforniassa, Yhdysvaltojen länsirannikolla. Ilmasto on miellyttävä ja pääasiassa lämmin. Läheltä löytyy suuria kaupunkia kuten San Francisco, Fresno ja San Jose, mutta myös paljon pienempiä kyliä, jossa voi nauttia rauhallisemmasta elämästä. Työntekijöitä on siis helppo houkutella Piilaakson miljööseen.

Pelkkä miellyttävä ilmasto ja viihtyisät kaupungit eivät kuitenkaan takaa hedelmällistä maaperää startup-kulttuurille. Syyt Piilaakson erinomaisuudelle startup-kulttuurissa löytyvät alueen historiasta.

Charles David Herrold rakensi 1900-vuosikymmenellä oman radiolähettimensä. Ensimmäinen radiolähetys tapahtui vuosikymmenen lopulla ja vuonna 1912 alkoi säännöllinen radio-ohjelmien lähettäminen. [14]

Vuonna 1912 alueella myös perustettiin Alco Hydro-Aeroplane Company -yritys [16], joka sittemmin vaihtoi nimensä Lockheediksi ja on nykyisin osa Lockeed Martin -konsernia [17]. Myöhemmin Yhdysvaltain laivasto päätyi sulkemaan oman toimintansa alueella ja siirsi toimitilansa NASA:lle [18].

High technology -osaamista on siis löytynyt alueelta jo pitkään. Kenties merkittävin panostus alueen tulevaisuuteen tehtiin vuonna 1950-luvulla, kun muun muassa Frederick Termanin ansiosta lähellä sijaitse Stanfordin yliopisto ja alueen high technology -yritykset perustivat yhteisen Stanford Industrial Parkin. Ensimmäinen yritys alueella oli Varian Associates Inc. Pian perässä seurasivat muun muassa Frederick Termanin oppipoikien Bill Hewlettin ja David Packardin Hewlett-Packard, General Electric, Eastman Kodak ja Lockheed. [19]

Vuonna 2011 Piilaaksossa toimineiden yritysten joukossa ovat muun muuassa Hewlett-Packard, Apple, Intel, Cisco Systems, Oracle, Google, eBay, AMD, Yahoo, Symantec, Sandisk, Nvidia, Electronic Arts, VMware, Netflix ja McAfee. [21]

Venture capital -sijoittajat ovat erityisen kiinnostuneita Kaliforniassa. CB Insightsin tekemän tutkimuksen mukaan 44% vuoden 2010 kolmannen kvartaalin VC-rahoituksesta meni Kaliforniaan. Seuraavana tuleva New York sai vain 16% ja sitä seuraava Massachusetts, jossa muun muassa Boston ja Cambridge sijaitsevat, sai vain 11%. [20]

Myös uusien pätevien työntekijöiden löytäminen on helppoa Piilaaksossa. Aivan Piilaaksossa ovat esimerkiksi Palo Altossa sijaitseva Stanfordin yliopisto ja Berkeleyssä sijaitseva Berkeleyn yliopisto.

Global Venture Labin Christian Aspegrenin mukaan niin sanottuja vahvoja sidoksia – suoria yhteyksiä – arvostetaan liikaa. Vahvoista sidoksista muodostetut verkostot ovat väkisinkin pienempiä, koska yksittäiset ihmiset eivät voi olla tekemisissä kovin laajan ihmismäärän kanssa. Siksi kannattaisikin suosia enemmän heikkoja sidoksia eli epäsuoria yhteyksiä, jossa ei hyödynnetäkään esimerkiksi suoraan ystävää tai sukulaista, vaan löydetään yhteistyökumppaneita omien vahvojen sidosten ystävistä tai heidän ystävistään. Koska Piilaakson alueella on paljon yrityksiä, rahoittajia ja yliopistoja, on helppo luoda tällaisia heikkojen sidosten verkostoja. Esimerkiksi Oklahoma Cityssä perustettava yritys on paljon kalifornialaista kilpailijaansa heikommassa asemassa.

Hautomon tuloksia

Rahoitettujen startup-yritysten määrä ei merkitsisi mitään, jos yritysten joukosta ei löytyisi menestyksiä. Y Combinatorin rahoittamia menestyneitä startup-yrityksiä ovat muun muassa Airbnb, Reddit, Loopt, Scribd ja Dropbox [4].

Airbnb on palvelu, johon käyttäjät voivat ilmoittaa asuntonsa tai talonsa tilapäisesti vuokrattavaksi ja muut käyttäjät voivat selata ilmoituksia varatakseen itselleen majoituksen. Airbnb tarjoaa vaihtoehdon hotellimajoituksille. [10]

Reddit on sosiaalinen uutispalvelu, jossa käyttäjät tuottavat sisällön sekä kommentoivat ja arvioivat muiden sisältöä.

Loopt tarjoaa mobiilipalvelun, jonka avulla käyttäjät voivat löytää lähialueeltaan uusia ystäviä, paikkoja ja tapahtumia.

Scribd on web-palvelu, jonka avulla käyttäjät voi helposti tuottaa dokumentteja ja jakaa niitä eri muodoissa tai liittää niitä web-sivuille.

Kenties kuuluisin Y Combinatorin hautomista yrityksistä on Dropbox. Dropbox on toteuttanut samannimisen palvelun, jonka asiakasohjelmiston käyttäjä voi asentaa useammalle tietokoneelle tai mobiililaitteelle. Laitteisiin lisätään erityinen Dropbox-hakemisto, johon käyttäjä voi laittaa tiedostojaan, jotka synkronoidaan käyttäjän jokaisen Dropbox-laitteen välillä. Näin esimerkiksi iPhonella otetut kuvat voidaan siirtää Dropbox-hakemistoon, jonka jälkeen käyttäjä voi katsella kuvia omalta kotikoneeltaan. Käyttäjän on mahdollista jakaa tiedostoja myös ystävilleen. Yritysmaailmassa ja tietokoneharrastajien keskuudessa tiedostojen siirtäminen oli arkipäivää jo ennen Dropboxia, mutta peruskäyttäjille ei löytynyt helppoja työkaluja. Tiedostojen siirtäminen vaati yleensä hankalia palvelinohjelmistoja, joille käyttäjän piti osata asettaa esimerkiksi palomuuriasetukset. Dropboxin käyttäminen on ilmaista, mutta tehokäyttäjille on tarjolla maksullisia päivityksiä.

Dropboxilla oli 25 miljoonaa käyttäjää huhtikuussa 2011. [7] Lokakuussa 2011 Dropbox sai 250 miljoonaa B-sarjan rahoituskierroksella, joka nosti yrityksen markkina-arvon arvion 4 miljardiin dollariin. Käyttäjämäärä oli kasvanut 45 miljoonaan käyttäjään. [8] Applen toimitusjohtaja Steve Jobs oli vuonna 2009 tarjoutunut ostamaan Dropboxin 9-numeroisella summalla. [9]

Ohjelmistoalan palveluiden tarjoaminen on erinomainen valinta yritykselle, joka haluaa aloittaa pienellä sijoituksella, mutta kasvaa mahdollisesti hyvinkin nopeasti valtavaksi. Koska ohjelmistot hoitavat varsinaisen palvelun tarjoamisen, on palvelun skaalaaminen jopa kymmenille miljoonille käyttäjille vain tekninen ongelma, jonka ratkaiseminen ei vaadi parhaimmillaan kuin kourallisen työntekijöitä. Tämä eroaa merkittävästi esimerkiksi ohjelmistoprojektien toteuttamista tai konsultointipalveluita tarjoavista yrityksistä, joiden skaalautuminen vaativaksi vaatii lähes poikkeuksetta myös yrityksen työntekijöiden määrän skaalamisen valtavaksi.

Tämän tyyppiset yritykset ovat myös rahoittajien mieleen. Esimerkiksi vuonna 2004 perustettu Facebook on seitsemässä vuodessa kasvanut 800 miljoonan käyttäjän palveluksi [11] ja jonka ennakoidaan listautuvan pörssiin vuonna 2012: talousanalystit ovat arvioineet yrityksen markkina-arvon olevan tuolloin huikeat 100 miljardia dollaria [12].

Ohjelmistoalan nopealla vauhdilla ja hurjilla markkina-arvoarvioilla on mielestäni myös varjopuolensa. Esimerkiksi radikaalin uuden idean kehittäneen startup-yrityksen myyminen isolle ja vanhoihin kaavoihinsa kangistuneelle markkinajohtajalle ei vie yhteiskuntaa eteenpäin, vaikka se tuottaakin yrityksen perustajille ja sijoittajille nopeasti rahaa.

Facebookin perustaja Mark Zuckerberg totesi lokakuussa 2011, että jos hän saisi aloittaa yrityksensä alusta, hän ei olisi muuttanut rakentamaan yritystä Piilaaksoon, vaan olisi pysynyt Bostonissa. Zuckerbergin mielestä alueella keskitytään liian paljon lyhyen tähtäimen saavutuksiin ja ihmiset eivät sitoudu tekemiinsä asioihin. Zuckerbergin mukaan myös Amazon.comin toimitusjohtaja Jeff Bezos on samaa mieltä. Bezosin mukaan työntekijät pysyvät yhdessä työpaikassa Piilaaksossa vain puolet siitä ajasta kuin Seattlessa, missä Amazon.comin päämaja sijaitsee. [15]

Myös Steve Jobs on kritisoinut alueelle tyypillistä kulttuuria: “I hate it when people call themselves ‘entrepreneurs’ when what they’re really trying to do is launch a startup, so they can cash in and move on. They’re unwilling to do the work it takes to build a real company, which is the hardest work in business. That’s how you really make a contribution and add to the legacy of those who went before. You build a company that will still stand for something a generation or two from now. That’s what Walt Disney did, and Hewlett and Packard, and the people who built Intel. They created a company to last, not just to make money.” [13]

Lähteet

[1] Y Combinator, 3.11.2011.

[2] Paul Graham, Beating the Averages, 3.11.2011.

[3] Inc. Magazine, The Start-up Guru, 3.11.2011.

[4] Wired Magazine, Y Combinator Is Boot Camp For Startups, 3.11.2011.

[5] Paul Graham, Ramen Profitable, 3.11.2011.

[6] Paul Graham, California Year-Round, 4.11.2011.

[7] GigaOm, Why Dropbox’s 25 Million Users Are Just the Start, 4.11.2011.

[8] TechCrunch, Dropbox Raises $250M In Funding, Boasts 45 Million Users, 4.11.2011.

[9] Forbes, Dropbox: The Inside Story Of Tech’s Hottest Startup, 4.11.2011

[10] Airbnb, About, 4.11.2011.

[11] Mashable, Facebook Now Has 800 Million Users, 4.11.2011.

[12] CNBC, Facebook IPO Valuation Could Top $100 Billion: Sources, 4.11.2011.

[13] Walter Isaacson, Steve Jobs, Simon & Schuster, 2011.

[14] SFGate, A forgotten genius on your radio dial, 4.11.2011.

[15] International Business Times, Zuckerberg Prefers Boston To Silicon Valley, 4.11.2011.

[16] U.S. Centennial of Flight Commission, The First U.S. Aircraft Manufacturing Companies, 4.11.2011.

[17] Lockheed Martin, Lockheed Martin History, 4.11.2011.

[18] NASA, Ames History, 4.11.2011.

[19] Palo Alto History, The Stanford Research Park: The Engine of Silicon Valley, 4.11.2011.

[20] New York Observer, New York Beating Boston in Number of New Startups, 4.11.2011.

[21] Mercury News, 2011 Silicon Valley 150 listings: Nos. 1-75, 4.11.2011.

[22] Y Combinator, Partners, 4.11.2011.

[23] Jessica Livingston, Founders at Work, Apress, 2008.

[24] European Union, Official EU Languages, 4.11.2011.

[25] Paul Graham, Why Startups Condense in America, 4.11.2011.

What were they thinking with these changes!

Let’s start from the front page. I’m not an expert but I think that the most used function of their website is the search for train timetables. Previously this was presented right on the first page. Apparently they deemed that unnecessary:

This would be merely stupid if this was the only design flaw. After entering the webshop I was presented with this:

Umm… I would have liked to look at the timetable and then buy tickets. Two of them actually. So should I choose “View timetable”, “Buy tickets” or “Multi-ticket seat reservation”? Let’s try “Multi-ticket seat reservation.” *click*

What is a multi-ticket order number? Where can I get it? Apparently I shouldn’t have chosen this. Maybe I’ll just look at the timetables after all.

Reasonable enough. *click*

By looking a the breadcrumb links above I thought that we already were on Timetables page in the previous page. Oh well, onto the next page. I’ve already spent 10 minutes figuring out this order and I’m only on the third page of an eight-page process. Or is it the fourth page? Now I’m confused.

Now we can choose our train. Again. At this point my friend had already decided that he didn’t need the train ride after all. So, let’s go back to the previous page and change that.

What the hell! Not this page again. *sigh* Let’s input all the values again.

“Please note that the selected seats to ensure only once the order has been added to your basket.” Umm… Okay. Noted. I guess.

After this the rest of the process went quite painlessly, actually. But then again, there was confusion enough for one order.

It’s always depressing to see that some good product has been taken for redesigning and after spending a lot of work on it, presenting the new and worse version. Of course even the presentation didn’t work quite as planned: the whole website crashed and hundreds of people couldn’t make their reservations.

UPDATE: Apparently their website wasn’t the only one that crashed.Their ticket counters were also closed due to IT problems.

Goodbye to the paper.

Goodbye to the piles of magazines filling your hallway. Goodbye to the endless rows of books gathering dust, fading pages. Goodbye to curled page corners and bookmarks lost in your bedsheets. Goodbye to splashes of food and drink on the pages.

Digital books and magazines are nothing new but reading them by sitting in front of a computer always felt awkward. Maybe it’s because I’ve never been the one to read sitting in a chair.

My first positive experience with a digital book came just a year ago when I ended up buying Surely You’re Joking, Mr. Feynman from Amazon Kindle to my phone. At first the higher price compared to the paperback version and the small, under 4-inch display felt discouraging but this feeling faded quick enough.

One of the most memorable experiences with a digital book was when I was eating in Subway and waiting for an hour for my friend. Being bored I wished that I’d brought something entertaining with me until I remembered that I indeed had. After balancing the phone on the edge of the tray I found the clock racing as I flipped through pages. Eating and reading have always been two of my favorite things to combine and by going digital it became much easier.

The full-on revolution started after I bought a tablet. The bigger screen and better reading software were a big plus. Even bigger ones were the easy availability of good magazines such as Time and Wired. Living in Finland makes ordering these foreign magazines a tad difficult but having them delivered to my tablet as soon as I they became available made the reading so much easier.

Here’s a thought for those who resist the idea of switching to digital books: imagine yourself in your bed, a bit tired but wanting to starting some new book but not having anything in your bookshelf. How about if you could have one in your hands in less than a minute? Today, there’s no longer nothing stopping you.

For a social network, obviously one of the most important requirements is that it has people in it. With everyone and their parents having joined Facebook and Twitter having become such an important communication service that even the President of the United States is using it to coordinate questions for his Twitter town hall meeting [4], how can one persuade people to switch to Google+?

Of course some have valid gripes with Facebook’s policies regarding privacy and might have been waiting for an alternative to leap to. But is this is enough to drive the critical mass from Facebook to Google? And are the policies of Google actually better? Google recently announced that they would be deleting all the private Google profiles and only allow public profiles in the future [5]. This is a natural decision for Google – they run The Search Engine after all – but is this a natural decision for users?

One of the most important arguments for me for moving to Google+ is the better user experience in sharing stuff with only certain groups – or Circles as Google refers to them. However Facebook already has support for similar sharing restrictions albeit with a poorer UX. I’ve actually only tried this once recently and ended up sharing my status post with everyone else except the ones I actually tried to share to. Yikes! If the easier restricting of sharing proves to be a major selling point, I’m sure Facebook will devote a lot of attention on improving their implementation – well before the critical mass of the users end up switching to Facebook’s competitor.

I dislike the fact that Twitter and Facebook, two privately owned companies with China rumoredly eyeing the shares of Facebook [6], have become such powerhouses in the world of social media. For this reason I’m glad that Google is stepping into the fight. Even if the balances of power will not be tipped, healthy competition surely won’t be a bad thing for the users. However if a non-techie friend of mine asks for what for she should to switch to Google+ – to move all their photo albums and profile descriptions, persuading their friends to make the switch to – for the time being my answer will be: “Nothing.”

References:

1. http://singularityhub.com/2011/07/06/google-is-awesome-facebook-maimed-twitter-mortally-wounded/
2. http://www.usatoday.com/tech/news/2011-07-06-facebook-skype-growth_n.htm
3. http://www.bbc.co.uk/news/business-12889048
4. http://www.huffingtonpost.com/john-robinson/askobama-askyourself_b_892117.html
5. http://www.pcmag.com/article2/0,2817,2388120,00.asp
6. http://www.zdnet.com/blog/facebook/rumor-china-wants-to-buy-a-stake-in-facebook/1909

Some people argue that these days the graphics are so good that further improvements are unnecessary. I disagree.

It’s true that for some games the limit has just about been reached. For example reconstructing a Formula 1 race in a way that’s almost indistinguishable from a TV broadcast is achievable. This is because a race settings consist mostly of quite static elements such as the track and the cars. Static elements are a lot simpler to model. Of course cars move but they don’t usually change shape if not for a collision. The audience is also quite distant most of the time. For these reasons lacking details won’t distract the gamers from the immersion of the game.

I think that the most graphically demanding games deal with a rather surprising genre: human drama. When you’re trying to convince the gamer that the characters in the game are real people that they should care about, the minute details can break or make the game.

Graphical glitches which are often present in games are especially distracting in serious drama games. If your character can accidentally fly or see through walls, the realism is quite easily shattered.

Even more difficult is recreating the human face. We human beings develop our face recognition skills at a very early age and from then rarely a day goes by without using it in some capacity. That’s why it’s so difficult to model a real human face: they are so familiar to us.

In my opinion human faces in games have been unrealistic until just recently. Heavy Rain from last year and L.A. Noire from this one have really pushed the envelope.

Heavy Rain is a game dealing with very serious concepts such as a loss of a child. The game consists of some actions scenes but the most important part of the game is telling a human story which would be impossible if not for the most advanced facial modeling.

L.A. Noire takes a step even a bit further: the main gameplay aspect is observation of people’s faces. Your character is a police detective interviewing suspects. Breaking a murder case might depend on noticing a small tell of a lying suspect.

Although Heavy Rain and L.A. Noire are quite merited I would argue that you couldn’t fool a viewer into confusing them with a real video of real people. I think succeeding in this might be the most important milestone since the dawn of 3D games.

And that is why graphics improvements still matter.

I’ve minored in mathematics in University of Jyväskylä but the explanations of complex numbers, pi and e among others on this site were way better than in my classes.

It’s unfortunate that most of the mathematics classes emphasize memorization of difficult formulas instead of explaining the concepts and showing examples of why they’ve been invented and why they are so useful. Some might argue that proving the formulas is the same as explaining them but I’ve found that I usually just end up memorizing the proofs instead of understanding them.

Of course I have to accept part of the blame. I could have used more of my own time to find explanations for these concepts but finding books that explain the concepts of university level mathematics in a simple manner without oversimplification is quite hard.

I think that the current situation is sustained because of two main reasons:

Firstly the professors of mathematics are usually mainly researchers and are forced to teach classes. Because they are so well versed in their subject, it’s very difficult to understand the perspective of novice students. This added with the lack of motivation leads to teachers who don’t even try to put themselves in the shoes of students and who just wish that they were back in their rooms continuing their research.

Second reason is academic arrogance. Unfortunately some of the academics show off their education by using difficult, long words and overly complex explanations. They think that all university students should be able to understand in the same way or else they are stupid. This is not true. Paraphrasing Einstein: “Everything should be made as simple as possible, but no simpler.” Solving difficult problems with science should be all that matters. Everything else is just ego tripping.

Unfortunately the situation in Finland is unlikely to change anytime soon. Because Finland is in the top places in international PISA rankings, there is no hurry to make things better.

Why bother?

This is already the best. Allegedly.

Jos tutkielman lukemisen jälkeen kiinnostaa tutustua yksityiskohtaisemmalla tasolla kielten eroihin, suosittelen lukemaan kirjoittamani esseen Javasta C#:iin: Erot pintaa syvemmältä.

Tutkielman PDF-versio on saatavilla JYX-julkaisujärjestelmästä.

Tiivistelmä: Tutkimuksen tavoitteena on selvittää, miten ohjelmoijan Java-osaamista voidaan hyödyntää C#-kielen opiskelussa tai toisinpäin. Helppo siirtyminen antaisi muun muassa yrityksille enemmän joustavuutta rekrytointiin, koska palkattavan työntekijän tuntemus tietystä käytettävästä kielestä ei olisi niin tärkeää kuin käytettävän kielen nopea oppiminen valmiita taitoja hyödyntäen. Tutkimus tehtiin vertailemalla kielistä julkaistuja ohjelmointioppaita, rajanpintakuvauksia ja kielten teknisiä spesifikaatioita. Tutkimuksen tulosten perusteella kielet ovat monessa suhteessa samankaltaisia, mutta erojakin on. Erot eivät ole haastavia ja Javasta C#:iin siirryttäessä ne tehostavat ohjelmointityötä. Tulosten perusteella siirtymät Javasta C#:iin tai toisinpäin ovat helppoja ja nopeita.

Abstract: The objective of the thesis was to find out if you can use existing Java experience to ease the learning of C# or vice versa. Easy moving from language to another would benefit for example companies’ hiring decisions as the candidate’s knowledge of a specific language would not be as important as an ability to learn the language quickly by using existing experience of another language. The study was done by comparing published programming tutorials, application programming interfaces and technical specifications. Based on the results of the study, languages are similar in many ways but there are some differences. These differences are not challenging and when moving from Java to C# they increase the productivity of the programming. The results suggest that learning C# by using existing Java experience or vice versa is easy and fast.

Avainsanat: Java, C#, ohjelmointikielet, oppiminen.

Keywords: Java, C#, programming languages, learning.

Sisältö

• Termilista
• 1 Johdanto
• 2 Java ja C#
  • 2.1 Käyttöalustat
  • 2.2 Kehitysympäristöt
• 3 Yhtäläisyydet
  • 3.1 Oliotyypit
  • 3.2 Arvotyypit
  • 3.3 Ohjelmointisyntaksi
  • 3.4 Virtuaalikoneet ja tavukoodi
• 4 Erot
  • 4.1 Luokat ja tietueet
  • 4.2 Muuttujatyyppien yhdenmukaisuus
  • 4.3 Ominaisuudet
  • 4.4 Operaattoreiden ylikuormitus
  • 4.5 Parametrinvälitys
  • 4.6 Delegaatit ja osoittimet
  • 4.7 Osittaiset luokat
  • 4.8 Lambda-lausekkeet
  • 4.9 Suoritusteho
• 5 Yhteenveto
• Lähteet

Termilista

• Konekoodi (engl. machine code) Ohjelmakoodia, jonka koneen prosessori osaa suorittaa.
• Tavukoodi (engl. bytecode) Ohjelmakoodia, jota ei voi suoraan suorittaa koneen prosessorilla, vaan jota suoritetaan virtuaalikoneella.
• Virtuaalikone (engl. virtual machine) Alusta, jonka päällä tavukoodia suoritetaan. Virtuaalikone tulkkaa tavukoodin konekoodiksi.
• Common Language Runtime Microsoftin .NET-kielten yhteinen virtuaalikone. Esimerkiksi C#- tai Visual Basic -koodista käännetään samanlaista tavukoodia, joka suoritetaan Common Language Runtimessa.
• Java Virtual Machine JVM-pohjaisten kielten yhteinen virtuaalikone. Javan lisäksi esimerkiksi Scala [8] ja Groovy [5] käyttävät JVM:ää tavukoodin suoritukseen.

1. Johdanto

Olio-ohjelmointikieliä on lukuisia erilaisia. Viime aikoina dynaamisesti tyypitetyt ohjelmointikielet kuten Python ja Ruby ovat saaneet huomiota, mutta staattiset tyypitetytkään kielet eivät ole katoamassa. Microsoftin kehittämä C# ja Sunin kehittämä Java ovat kaksi suosittua staattisesti tyypitettyä olio-ohjelmointikieltä.

Jyväskylän yliopistossa uusille opiskelijoille suunnatut Ohjelmointi 1- ja Ohjelmointi 2 -kurssit ovat viime vuosina järjestetty käyttäen Java-kieltä. Hyvä ohjelmoija ei kuitenkaan ole vain yhden kielen osaaja.

Tutkielmani tarkoitus on selvittää, miten Java-kieltä osaavat opiskelijat pystyisivät opettelemaan mahdollisimman helposti C#-kieltä. Kartoitan ensin kielten historiaa ja käyttötarkoituksia, jonka jälkeen tutkin, mitä yhteistä ja erilaista kielillä on. Teen tutkimukseni vertailemalla kielten opetusmateriaaleja ja ohjelmakoodiesimerkkejä.

2. Java ja C#

Sun Microsystemsin (myöhemmin Sun) työntekijä, James Gosling, aloitti Java-kielen kehityksen vuonna 1991. Kieli oli alunperin suunnattu käytettäväksi sittemmin unohdetussa kodin elektroniikkalaitteiden ohjaukseen tarkoitetussa *7-laitteessa (StarSeven). Jo alusta asti kielen tavoitteena oli olla prosessoririippumaton, jolloin samalla ohjelmointikielellä pystyttäisiin toteuttamaan sovelluksia useille eri alustoille. *7-laitteet suunniteltiin käytettäväksi digitaalikaapelitelevisioon liittyvissä interaktiivisissa palveluissa, joissa käyttäjät voisivat tuottaa sisältöä. Kaapelitelevisioyhtiöt vastustivat ajatusta, koska he halusivat pitää sisällön kontrolloinnin itsellään. Goslingin tiimissä oli jo 70 henkilöä, mutta selkeää käyttötarkoitusta kielelle ei ollut kaapelitelevisioyhtiöiden kieltäytymisen takia. John Gage, James Gosling, Patrick Naughton, Wayne Rosing ja Eric Schmidt kokoontuivat miettimään uutta käyttötarkoitusta ja he päätyivät tutkimaan mahdollisuuksia Javan käyttöön Internetissä. [2]

1990-luvun loppupuolelle asti Windows-ohjelmistot kehitettiin edelleen lähes yksinomaan C- ja C++-kielillä, joiden muun muassa vaikeammasta muistinkäsittelystä johtuva monimutkaisuus piti ohjelmistonkehityksen monille vaikeana ja hitaana prosessina. Lisäksi Microsoftin kirjastojen käyttäminen sitoi kehitetyt ohjelmat Windows-ympäristöön.

Jos ohjelmistoja pystyisi käyttämään millä tahansa käyttöjärjestelmällä, ei Windowsia voisi enää markkinoida ylivoimaisella ohjelmatarjonnalla ja Microsoft menettäisi valta-asemansa. Estääkseen Javan kehittymisen merkittäväksi kilpailijaksi Microsoft teki läheisimmän yhteistyökumppaninsa, Intelin, kanssa yhteisen päätöksen kehittää kilpailija Javalle. Javan prosessoririippumattomuus oli uhka myös Intelille sen ollessa suurin prosessorivalmistaja. Microsoftin sisällä laadittiin toimintastrategia, jossa Javan kehityksestä pyrittiin tekemään vaikeampaa niin, ettei koodin kirjoittaminen yhdelle alustalle ja sen ajaminen kaikilla muilla enää onnistunutkaan. Tämä onnistui toteuttamalla Windowsille oma Java-virtuaalikone, joka oli Sunin virallista tehokkaampi, mutta käytti epästandardeja J++-nimellä kulkeneita laajennuksia. Näennäisesti Microsoft jatkoi edelleen Javan tukemista omalla alustallaan, mutta pyrki saamaan oman Windowsiin sidotun ratkaisunsa kehityksessä Javan ohi. Sun ei pitänyt Microsoftin aiheuttamasta uhasta tuotettaan kohtaan ja vuonna 1998 Sun haastoi Microsoftin oikeuteen. [3] Syytteen perusteluiksi Sun esitti Microsoftin rikkoneen lisenssiehtoja, joista Sun ja Microsoft oli sopineet vuonna 1995. [25]

Oikeustaistelu varjosti Microsoftin Java-toteutuksen tulevaisuutta ja Microsoftin suunnittelema uusi pohja omaa korvaavaa kieltä varten lopetti J++:n jatkokehityksen. Vuonna 1999 Microsoft perusti Anders Hejlsbergin johdolla kehitysryhmän C#-ohjelmointikieltä varten. Kieli otti vaikutteita muun muassa Pascalista ja Javasta. Erityisen paljon vaikutteita on antanut Delphi, koska Hejlsberg työskenteli edellisessä työpaikassaan Borlandilla yhtenä Delphin pääkehittäjistä. [6]

Oikeustaistelu sovittiin oikeussalien ulkopuolella vuonna 2004 ja Microsoft maksoi 1,95 miljardia dollaria korvauksia ja lisenssimaksuja Sunille. [4]

2.1 Käyttöalustat

Kuten edellisessä luvussa selvisi, Java on alusta asti suunnattu käytettäväksi useilla eri alustoilla. Näin ohjelmiston toteuttava organisaatio ei joudu sitoutumaan vain yhteen laitealustaan, jonka tulevaisuuteen organisaatio ei voi suoraan vaikuttaa. Kaikille alustoille Java-virtuaalikonetta ei ole kehitetty, mutta muun muassa Windowsin, Mac OS X:n, Linuxin ja BSD-varianttien tukeminen kattaa suuren osan maailman tietokoneista. Microsoftin virallinen tuki C#:lle kattaa Windows-työpöydän, Xbox 360 -pelikonsolin ja Windows Mobile -laitteet.

C# ja siihen olennaisesti liittyvät kirjastot eivät kuitenkaan ole sidottu pelkästään Windowsiin. Mono on Novellin johtama projekti, jonka tavoitteena on kehittää useilla eri käyttöjärjestelmillä toimivat avoimen lähdekoodin versiot näistä työkaluista. Kirjoitushetkellä Monosta on toteutettu viralliset versiot Windowsille, Linuxille, Mac OS X:lle ja Solarikselle. Koska projekti ei ole Microsoftin toteuttama, kaikki Microsoftin kehittämät ominaisuudet eivät ole käytettävissä, mutta kattava osa näistä on kuitenkin jo toimivia. Myös Microsoftin Silverlight-web-teknologiasta on muilla alustoilla toimiva Mono-projektin alainen Moonlight-käännös. [24]

2.2 Kehitysympäristöt

Javalle ei ole yhtä virallista kehitysympäristöä, mutta hyvin suosituksi valinnaksi on osoittautunut alunperin IBM:n VisualAge-ohjelmiston pohjalta kehitetty Eclipse Foundationin Eclipse. Eclipse itsessään on kehitetty Javalla ja sillä on mahdollista kääntää sovelluksia jokaiselle Java-virtuaalikonetta tukevalle alustalle. Toinen suosittu kehitysympäristö on Sunin NetBeans. Ominaisuuksiltaan ja käytettävyydeltään nämä kaksi ovat hyvin lähellä toisiaan.

Visual Studio on Microsoftin tarjoama kehitysympäristö, jolla pystytään kehittämään muun muassa C#-ohjelmia. Siitä on olemassa kaupallinen ominaisuuksiltaan monipuolisempi versio, mutta myös harrastelijoille ja opiskelijoille suunnattu kevyempi, ilmainen Visual Studio Express. Visual Studio toimii vain Windows-ympäristössä, mutta sillä voidaan kehittää muillakin alustoilla toimivia sovelluksia käyttämällä Mono-kääntäjää.

3. Yhtäläisyydet

Java ja C# ovat molemmat staattisesti tyypitettyjä olio-ohjelmointikieliä. Ohjelma koostuu yhdestä tai useammasta luokasta. Luokat sisältävät olio- ja arvotyyppejä. Kun ohjelmakoodi on valmis, se käännetään kääntäjäohjelmalla tavukoodiksi. Tavukoodia ei pysty suoraan suorittamaan koneella, vaan se suoritetaan virtuaalikoneessa, joka tulkkaa tavukoodin käyttöjärjestelmälle sopivaksi binäärikoodiksi.

3.1 Oliotyypit

Oliot ovat tietorakenteita, joilla on tietokenttiä ja metodeja eli olion liittyviä funktioita. Oliotyyppiset muuttujat ovat viitteitä olion ensimmäiseen muistipaikkaan. Olion tietorakenteeseen tallennetaan olion tyyppi, arvotyyppiset muuttujat ja viitteet oliotyyppisiin muuttujiin. Lisäksi olio tarvitsee metodiensa sijainnin muistissa.

3.2 Arvotyypit

Javan ja C#:n arvotyyppiset muuttujat ovat keskenään hyvin samankaltaisia. Arvotyyppeihin säilötään totuusarvoja, yksittäisiä merkkejä ja kokonais- ja desimaalilukuja. Arvotyypit on esitelty taulukossa 1 [11].

Primiitivien nimet ovat kielissä lähes identtiset. Eroina totuusarvotyyppi on Javassa nimeltään boolean ja C#:ssa bool sekä 8-bittinen kokonaisluku on Javassa byte ja C#:ssa sbyte.

Nimeämiserojen lisäksi C#:ssa on omat tyypit etumerkittömille (engl. unsigned) kokonaisluvuille. Javassa kaikki desimaali- ja kokonaisluvut voivat olla positiivisia tai negatiivisia. Jos haluamme käsitellä pelkkiä positiivisia lukuja, joudumme kirjoittamaan ohjelmakoodiin logiikan, joka tarkistaa lukujen positiivisuuden.

3.3 Ohjelmointisyntaksi

Hello World -esimerkki on todennäköisesti monille opiskelijoille tuttu. Java-kielellä se toteutetaan seuraavasti:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.writeln("Hello World!");
  }
}

Luodaan HelloWorld-luokka, johon määritellään julkinen staattinen main-metodi. main-metodi ottaa parametrikseen merkkijonotaulukon, joka sisältää mahdolliset komentoriviltä annetut argumentit. main-metodissa kutsumme Javan järjestelmäkirjastoista System.out.writeln-metodia, joka tulostaa rivin Hello World.

public class HelloWorld {
  public static void Main(string[] args) {
    System.Console.WriteLine("Hello World!");
  }
}

Java ja C# lainaavat suuren osan syntaksistaan C-kieleltä, joten Javasta C#:iin siirtyessä ei tarvitse opetella täysin uutta syntaksia. Koodiesimerkeistä voidaan huomata, miten ohjelmat ovat lähes identtisiä. Suurin ero on, että C#-ohjelmissa luokat määritellään nimiavaruuden (engl. namespace) alle ja Javassa ne määritellään pakettiin (engl. package). Nimiavaruudet ja paketit ovat käsitteinä samoja, mutta niiden toteutukset poikkeavat [14].

3.4 Virtuaalikoneet ja tavukoodi

Nykyajan tehokkaat tietokoneet ja korkean tason ohjelmointikielet piilottavat suuren osan siitä, mitä koneen sisällä tapahtuu ohjelmaa ajettaessa. Kun tietokoneet olivat huomattavasti nykyistä tehottomampia, ei ollut varaa tuhlata suorituksen kellojaksoja. Tällöin ohjelmat kirjoitettiin Assembly-kielellä, joka on hyvin matalan tason ohjelmointikieli. Se on tehokas, koska ohjelmoija kirjoittaa koodiin jokaisen operaation, joka ohjelman ajamisen aikana suoritetaan. Koska ohjelmointi tehdään laitetasolla, kirjoittaminen on hidasta ja virhealtista ja toiselle käyttöjärjestelmä- tai laitealustalle siirtyminen saattaa vaatia huomattavia muutoksia koodiin.

Koneiden nopeutuessa yksittäisten kellojaksojen arvo ei ollut enää yhtä suuri kuin aiemmin, joten ohjelmat voitiin kirjoittaa korkeamman tason kielillä, jotka piilottavat kehittäjältä osan ohjelman monimutkaisuudesta. Korkeamman tason kielellä kirjoitetut ohjelmat muutetaan kääntäjällä Assembly-koodiksi, jota tietokone osaa suorittaa. Nyt toiselle käyttöjärjestelmä- tai laitealustalle siirtyminen on helpompaa, koska ohjelmakoodi voidaan parhaassa tilanteessa kirjoittaa vain kerran. Kun otetaan käyttöön uusi alusta, kirjoitetaan sille sopiva kääntäjä. Kääntäjä kääntää aiemmin kirjoitetun ohjelmakoodin uuden alustan ymmärtämäksi konekoodiksi. Usein siirtyminen ei kuitenkaan aivan näin yksinkertaista ole, vaan esimerkiksi Windowsista Linuxiin siirryttäessä joudutaan muokkaamaan tiedostonkäsittelyyn liittyviä osia, koska Windows ja Linux käsittelevät tiedostojärjestelmää eri tavoin.

Kun ohjelmakoodi muutetaan kääntäjällä tietylle alustalle sopivaksi ohjelmaksi, sen kopioiminen toiselle alustalle ei onnistu. Jotta siirtyminen alustalta toiselle onnistuisi ilman uutta käännöstä, muun muassa C#:ia ja Javaa ei käännetä suoraan konekoodiksi, vaan tavukoodiksi. Tavukoodia ei suoraan voi suorittaa koneella kuten konekoodia, vaan väliin tarvitaan virtuaalikone, joka kääntää tavukoodin pyytämät operaatiot konekoodiksi. Kun ohjelmaa halutaan käyttää uudella alustalla, voidaan vanhaa ohjelmatiedostoa suorittaa uudelle alustalle kehitetyllä virtuaalikoneella.

4. Erot

Javasta on mahdollista siirtyä C#:iin kirjoittamalla lähes täysin samanlaista koodia kuin Javalla kirjoittaisi, mutta tällöin kielestä toiseen siirtyminen ei tuo merkittäviä etuja, koska C#:stä löytyy useita tekniikoita, jotka mahdollistavat lyhyempiä ja tehokkaampia tapoja kirjoittaa sama ohjelmalogiikka.

Javan versiota 6 ja C#:n versiota 3 vertaillessani ei löytynyt ainoatakaan eroa, jossa Javan toteutus olisi teknisesti tai ohjelmointityön helppouden kannalta ylivoimainen C#:n toteutukseen verrattuna. Tästä ei kuitenkaan voi vetää johtopäätöstä, ettei Javalla ole sijaa ohjelmistokehityksessä ja että C# olisi jokaiseen tilanteeseen parempi ratkaisu. Suurin osa eroista ovat pieniä ja suhteellisen helposti kierrettäviä suoritustehon tai käyttäjäystävällisyyden kustannuksella. Lisäksi ohjelmointikielen valintaan vaikuttavat lukuisat tapauskohtaiset yksityiskohdat, joten yleispätevän suosituksen antaminen ei ole järkevää.

4.1 Luokat ja tietueet

Javassa primitiivimuuttujien lisäksi on olemassa vain erilaisia luokkia. C#:ssa on tietueita ja luokkia. C#:in primitiivimuuttujat on toteutettu tietueilla [18]. Tietue on paremmin C-ohjelmointikielestä tuttu tietorakenne. C:ssä näihin pystyi tallentamaan vain primitiivimuuttujia: funktioita ei pystynyt kirjoittamaan suoraan tietueen sisälle. C#:ssa tietueisiin sopivat kuitenkin funktiot, konstruktorit, operaattorifunktiot ja tapahtumat. Tietueiden periminen ei ole mahdollista, mutta ne voivat kuitenkin toteuttaa rajapintoja samoin kuin luokatkin. [22]

Luokista poiketen tietueiden muisti varataan pinosta, eikä dynaamisen muistinhallinnan keosta. Lisäksi uuden tietueen luominen on uuden olion alustamiseen verrattuna kevyt operaatio.

4.2 Muuttujatyyppien yhdenmukaisuus

Javassa kaikki muuttujatyypit pystyttiin jaottelemaan primitiiveihin ja olioihin. Primitiivejä ovat kaikki, joiden muuttujatyyppi alkaa pienellä alkukirjaimella eli short, int, long, float, double, boolean, char ja byte. Primitiivimuuttujan muistiosoitteessa on suoraan muuttujan arvo. Kaikki muut muuttujatyypit ovat olioita, joiden muistiosoitteessa on viite olion sijaintiin.

Microsoftin mukaan C#:ssa muuttujia ei jaotella primitiiveihin ja olioihin, vaan kaikki periytyvät object-luokasta: näin esimerkiksi int-muuttujilta löytyy ToString-metodi, ja ne pystytään antamaan argumentteina metodille, joka hyväksyy argumentikseen object-tyyppisen olion. Tätä kielen ominaisuutta kutsutaan muuttujatyyppien yhdenmukaisuudeksi (engl. unified type system). [23]

Jos Javassa haluttaisiin toteuttaa esimerkiksi pino-olio, johon voidaan asettaa mitä tahansa muuttujia, primitiivimuuttujat tulisi muuttaa vastaaviksi oliomuuttujiksi:

public class Stack {
  public void push(Object input) { ... }
  public object pop() { ... }

  public void main(String[] args) {
    Stack stack = new Stack();
    stack.push(new Double(3.14));
    stack.push(new Integer(17));
  }
}

C#:ssa sama tapahtuisi seuraavasti [23]:

public class Stack {
  public object Pop() { ... }
  public void Push(object o) { ... }

  public void main() {
    Stack stack = new Stack();
    stack.Push(3.14);
    stack.Push(17);
  }
}

Olioita luodessa on varattava dynaamisesti muistia, suoritettava mahdolliset konstruktorimetodit ja luotava viite luotuun olioon. Arvomuuttujia käyttäessä tarvitsee vain tallentaa arvo staattisesti varattuun muistipaikkaan. Jos kaikki arvomuuttujat olisivat todellisuudessa olioita, suorituskyky kärsisi merkittävästi.

Esimerkiksi tieteellinen laskenta C#:llä olisi hyvin hidasta, koska yhden silmukkakierroksen aikana saatetaan luoda tuhansia muuttujia. Primitiivimuuttujien tapaan tehtävä suora tallennus muuttujan muistiosoitteeseen olisi nopea operaatio, mutta uuden olion luominen on sen sijaan merkittävästi hitaampi. Suoritustehon kasvattamiseksi arvomuuttujien käsittely suoritetaan suoraan muistiosoitteita käyttämällä. Vasta asetettaessa arvomuuttujaa olioon sen arvo kopioidaan olion sisään ja asetetaan muuttuja viittaamaan luotuun olioon. Vastaavasti asetettaessa olioa takaisin arvomuuttujaan arvo kopioidaan olion sisältä ja asetetaan suoraan muistiosoitteeseen. Näitä operaatioita kutsutaan boxing- ja unboxing-operaatioiksi. [23]

4.3 Ominaisuudet

Lähes kaikilla olioilla on attribuutteja, joiden arvoja tulee pystyä lukemaan olion ulkopuolelta. Yksi tapa toteuttaa tämä on asettaa attribuutit täysin tai osittain julkisiksi public- tai protected-avainsanoilla.

Attribuuttien asettaminen julkiseksi on kuitenkin huono tapa, ellei muuttujia ole asetettu vakioksi Javan final- tai C#:in const-avainsanalla, koska muulloin niiden arvoja pystytään myös muuttamaan olion ulkopuolelta. Tällöin syötettäviä uusia arvoja ei pystytä tarkistamaan ennen asettamista, eikä kohdeolio saa itse tietoa arvojensa muuttumisesta. Tämä rikkoo myös enkapsulaatioperiaatetta, jonka perusteella ohjelman pitäisi koostua komponenteista, jotka tarjoavat muille komponenteille käytettävän rajapinnan. Jos muut komponentit käyttävät suoraan toisen komponentin sisäisiä arvoja, on niiden toteutus riippuvainen tietystä komponentin toteutuksesta ja kyseisen komponentin vaihtaminen vaihtoehtoiseen toteutukseen olisi tarpeettoman työlästä.

Yleiseksi tavaksi on muodostunut asettaa attribuutti salaiseksi private-avainsanalla ja kirjoittaa olioon julkiset getter- ja setter-metodit, joilla arvo pystytään lukemaan ja haluttaessa myös muuttamaan. Tämä johtaa niin sanottuun boilerplate-koodiin, jossa vain pieni osa koodista liittyy varsinaiseen toteutukseen [15].

public class User {
  private String username;

  public getUsername() {
    return this.username;
  }

  public setUsername(String value) {
    this.username = value;
  }
}

Valitettavasti Javassa tähän ei ole parempaa keinoa ja ainoa tapa vähentää boilerplate-koodin kirjoittamista on käyttää esimerkiksi kehitysympäristön makroja. C#:ssa sen sijaan on käytettävissä ominaisuudet (engl. properties):

public class User {
  public string Username { get; set; }
}

Tällä tavoin luokkaan määritellään yhdessä lohkossa julkinen ominaisuus, jonka sisällä get- ja set-avainsanoilla kerrotaan, mitä ominaisuuden arvoa luettaessa ja kirjoittaessa tehdään. Lohkosta voidaan jättää jompikumpi operaatio pois, jolloin ominaisuudesta tulee vain luettava tai vain kirjoitettava.

Esimerkkikoodissa on hyvin yksinkertainen tapaus, jossa kaikki arvot hyväksytään ja arvon lukeminen on sallittua, eikä vaadi erikoismuotoiluja. Vaikeammissa tapauksissakin ominaisuuksista on hyötyä, koska tällöin attribuutin lukemiseen ja kirjoittamiseen liittyvä logiikka on koottuna yhdessä paikassa. Myöskään eri luokkien välillä ei ole eroja getter- ja setter-metodien nimissä: ei ole siis esimerkiksi getName- ja writeName-nimisiä metodeja, vaan arvo luetaan aina syntaksilla olio.Ominaisuus ja uusi arvo asetetaan syntaksilla olio.Ominaisuus = uusiArvo.

private string email;
public string Email {
  get { return this.email; }
  set {
    if ( Validator.validateEmail(value) ) {
      this.email = value;
    }
  }
}

Yllä olevassa esimerkissä ominaisuuden arvoa asettaessa sille tehdään tarkistus ja vasta sen läpäistyään argumenttina annettu arvo asetetaan ominaisuudelle. Yleisen tavan mukaisesti salainen attribuutti ja julkinen ominaisuus ovat saman nimisiä, mutta ominaisuuden nimi on kirjoitettu isolla alkukirjaimella.

4.4 Operaattoreiden ylikuormitus

Operaattoreiden ylikuormituksella (engl. operator overloading) kehittäjän on mahdollista määritellä, miten kahden olion väliset aritmeettiset operaatiot ja yhtäsuuruusvertailut toteutetaan. Javassa operaattoreiden ylikuormitus ei ole kehittäjän määriteltävissä, mutta Sun on toteuttanut erikoistapauksena merkkijonojen yhdistämisen +-operaattorilla.

Kuormittamisen puuttumisen takia esimerkiksi matriisien yhteen- ja kertolaskun toteuttaminen on Javassa tehtävä erityisillä, mielivaltaisesti nimetyillä metodeilla, jotka ottavat parametrikseen toisen matriisin. Jo yksinkertaisesta matemaattisesta lausekkeesta tulee monimutkainen.

public class Matrix {
  public Matrix add(Matrix matrix) { /* ... */ }
  public Matrix multiply(Matrix matrix) { /* ... */ }

  public void main(String[] args) {
    Matrix matrix1 = new Matrix(/* ... */);
    Matrix matrix2 = new Matrix(/* ... */);
    Matrix matrix3 = new Matrix(/* ... */);

    matrix1.add(matrix2).multiply(matrix3);
  }
}

C#:n kanssa operaattoreiden ylikuormitus onnistuu määrittelemällä luokkaan staattinen metodi operatorX, jossa X on ylikuormitettava operaattori. Lista mahdollisesti ylikuormitettavista operaattoreista löytyy Microsoft Developer Network -palvelusta [20].

public class Matrix {
  public static Matrix operator+(Matrix m1, Matrix m2) { ... }
  public static Matrix operator*(Matrix m1, Matrix m2) { ... }

  public void main() {
    Matrix matrix1 = new Matrix(/* ... */);
    Matrix matrix2 = new Matrix(/* ... */);
    Matrix matrix3 = new Matrix(/* ... */);

    matrix1 = (matrix1 + matrix2) * matrix3;
  }
}

Matriisilaskenta yllä olevalla koodilla ei ole tehokasta. Jokaista laskutoimitusta kohden luodaan uusi matriisiolio. Esimerkiksi matrix1 + matrix2 luo uuden olion, joka kerrotaan matrix3-oliolla, jolloin syntyy jälleen uusi olio. Jos alkuperäisiä matriiseja ei ole tarvetta säilyttää, kannattaa esimerkiksi kertolaskun tulokset sijoittaa suoraan kerrottavaan matriisiin. Periaatteessa tämän voi toteuttaa operaattoreiden ylikuormituksellakin, jos kuormittavassa metodissa lasketaan lopputulos operandiin. Tämä tosin on epäloogista käyttäjän kannalta, koska hän ei pysty huomaamaan lausekkeesta matrix1 * matrix2, että matrix2:n arvo muuttuu. Koska operaattoreiden ylikuormituksella ei voi saavuttaa muuta kuin parempaa luettavuutta, olisi tällaisen ylikuormituksen tekeminen mieletöntä.

Sinänsä operaattoreiden ylikuormitus ei ole kuin kuorrutusta syntaksin päälle, mutta sillä on mahdollista yksinkertaistaa ja lyhentää monimutkaisia lausekkeita. Etenkin matemaattista ohjelmistoa kehittäessä laskukaavat näyttävät samankaltaisemmilta paperilla ja ohjelmakoodissa. Lisäksi vähempi koodimäärä ja loogisempi muotoilu edesauttaa virheettömyyttä.

Operaattoreita ylikuormittaessa on tärkeää muistaa tehdä vain loogisia ylikuormituksia: mitä toiminnallisuutta haluttaisiin esimerkiksi kuvata merkkijonojen --operaattoria kuormittaessa? Epäloogisilla ylikuormituksilla on helppo tehdä koodista vaikealukuista.

4.5 Parametrinvälitys

Javassa parametrinvälitys hoidetaan aina arvonvälitysmenetelmällä (engl. pass by value). Tämä tarkoittaa sitä, että kun metodia kutsuttaessa annetaan argumenttina jokin arvo, se kopioidaan metodin parametrille.

Arvomuuttujilla tilanne on yksinkertainen. Jos metodille annetaan argumenttina 3 ja metodissa tätä arvoa kasvatetaan, muutos näkyy ainoastaan metodin määrittelemällä näkyvyysalueella.

Olioiden kanssa tilanne on valitettavasti monimutkaisempi. Jos esimerkkimetodilla changeReference on parametri greetings ja kutsuvasta metodista annetaan argumentti greetingsArgument, parametriin kopioidaan arvoksi sama viite kuin argumentilla. Jos changeReference-metodissa viite asetetaan osoittamaan uuteen olioon, parametrin arvo vaihtuu, mutta argumentin arvo säilyy ennallaan, koska parametrin arvo oli vain kopio argumentista: ei siis sama viite. Jos esimerkkimetodissa useReference kutsutaan parametriolion append-metodia argumentilla Thanks!, sekä parametri että argumentti osoittavat kuitenkin edelleen samaan olioon, joten sekä suorittaja että vastaanottaja näkevät append-metodilla tehdyn muutoksen.

public class ReferenceTest {
  private static void changeReference(StringBuffer greetings) {
    greetings = new StringBuffer("Thanks!");
  }

  private static void useReference(StringBuffer greetings) {
    greetings.append(" Thanks!");
  }

  public static void main(String[] args) {
    StringBuffer greetingsArgument = new StringBuffer("Hello!");
    System.out.println(greetingsArgument.toString());
    changeReference(greetingsArgument);
    System.out.println(greetingsArgument.toString());

    StringBuffer goodbyeArgument = new StringBuffer("Goodbye!");
    System.out.println(goodbyeArgument.toString());
    useReference(goodbyeArgument);
    System.out.println(goodbyeArgument.toString());
  }
}

Ohjelman tulosteeksi saadaan:

Hello!
Hello!
Goodbye!
Goodbye! Thanks!

C#:ssa parametrinvälityksessä käytetään oletuksena samaa arvonvälitysmenetelmää, mutta tarvittaessa parametrit voidaan välittää myös viitteenvälitysmenetelmällä (engl. pass by reference). Tällöin kutsuttu metodi voi muuttaa annetun viitteen arvoa. Viitteenvälitys valitaan käyttöön ref-avainsanalla. Ref-avainsanaa on silloin käytettävä sekä metodin määrittelyssä että metodia kutsuttaessa, jottei metodi pääse yllättäen muuttamaan viitteen arvoa ilman kutsun suorittajan erillistä lupaa.

public class ReferenceTest {
  public static void setThanks(StringBuilder input) {
    input = new StringBuilder("Thanks!");
  }

  public static void setThanksByReference(ref StringBuilder input) {
    input = new StringBuilder("Thanks!");
  }

  public static void Main(string[] args) {
    StringBuilder greetings = new StringBuilder("Hello!");
    System.Console.WriteLine(greetings.ToString());
    setThanks(greetings);
    System.Console.WriteLine(greetings.ToString());
    setThanksByReference(ref greetings);
    System.Console.WriteLine(greetings.ToString());
  }
}

Ohjelman tulosteeksi saadaan:

Hello!
Hello!
Thanks!

4.6 Delegaatit ja osoittimet

Javassa ja C#:ssa metodeihin viittaaminen on toteutettu eri tavalla. Esimerkiksi graafisia käyttöliittymiä ohjelmoitaessa komponentille määritetään, mikä metodi sen tulee ajaa tietyn tapahtuman ilmetessä. Javassa suoraan metodiin viittaaminen ei ole mahdollista. Tämä kierretään yleisesti ohjelmoimalla kuuntelijarajapinnan toteuttava olio, joka sisältää tapahtuman ilmetessä ajettavan metodin. Alla esimerkki, kuinka painikkeen painallustapahtumaan liitetään kutsuttava metodi:

loginButton.addMouseListener(new java.awt.event.MouseAdapter() {
  public void mouseClicked(java.awt.event.MouseEvent evt) {
    loginButtonMouseClicked(evt);
  }
});

C#:ssa funktioihin viittaaminen onnistuu delegaateilla. C#:ssa on viitteiden ja delegaattien lisäksi myös esimerkiksi C-kielestä tutut osoittimet. Osoittimilla pystytään viittaamaan suoraan muistipaikkaan, jossa on primitiivimuuttuja tai tietue, joka sisältää primitiivimuuttujia [21].

4.7 Osittaiset luokat

Osittaiset luokat (engl. partial classes) mahdollistavat luokan jakamisen useampaan eri lähdekooditiedostoon. Näin esimerkiksi graafisissa käyttöliittymissä itse käyttöliittymän asettelu- ja muotoilukoodi voidaan eriyttää sen toiminnallisuutta kuvaavasta koodista ja lopputuloksena on selkeämpi kokonaisuus, jolloin kehittäjä voi keskittyä kulloinkin olennaiseen osaan.

Javassa osittaisia luokkia ei ole. Siksi yhden ikkunan ohjelmakoodissa on sekä käyttöliittymä komponenttien sijoittelu ja muotoilu että ikkunan käyttöliittymän logiikkakoodi. Esimerkiksi NetBeansillä käyttöliittymää kehittäessä tätä koodin paljoutta yritetään piilottaa tekemällä sijoittelu ja muotoilu niiden tekemiseen tarkoitetulla apuohjelmalla, eikä suoraan koodilla. Oletuksena NetBeans piilottaa tämän apuohjelman luoman koodin ja estää sen muokkaamisen. Muotoilu- ja sijoittelukoodi on kuitenkin samassa luokassa käyttöliittymän logiikan kanssa ja luokan koko kasvaa.

C#:ssa muotoilu ja sijoittelu sijoitetaan omaan tiedostoonsa, jota käyttäjän ei pitäisi joutua muokkaamaan suoraan ollenkaan. Luokan toiseen osaan jää vain käyttöliittymän logiikkaan liittyvä koodi. Osittaiset luokat sopivat myös muualle. Käyttöliittymäohjelmointi on vain yksi esimerkki niiden käytöstä.

4.8 Lambda-lausekkeet

C#:n lambda-lausekkeet ovat anonyymejä funktioita. [19] Anonyymit funktiot ovat nimensä mukaisesti nimettömiä funktioita. Anonyymejä funktioita käytetään usein tilanteissa, joissa funktiota ei tarvitse pystyä kutsumaan muualta ja funktio on suhteellisen yksinkertainen. Esimerkki tällaisesta tilanteesta on listojen läpikäynti tilanteessa, jossa listasta etsitään tietyn ehdon täyttäviä alkioita tai halutaan järjestää alkiot jotenkin muuten kuin alkioiden luonnolliseen järjestykseen. Alla esimerkki, miten kokonaislukutaulukosta voidaan laskea parittomien alkioiden lukumäärä:

public class LambdaExpressionExample {
  public static void Main(string[] args) {
    int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
    int oddNumbers = numbers.Count(n => n % 2 == 1);
    System.Console.WriteLine(oddNumbers);
  }
}

Count-metodille ei tarvitse antaa tyyppiparametriä. C#:in tyypin määrittely (engl. type inference) pystyy päättelemään geneerisen metodin tyypin argumenttien perusteella. [16] Count-metodi on määritelty muodossa Enumerable.Count Method (IEnumerable, Func). [17] Esimerkin lista numbers on tyyppiä IEnumerable, joten anonyymin funktion geneerinen tyyppi Func pystytään päättelemään eksplisiittiseksi tyypiksi Func.

Javassa ei ole mahdollista tehdä lambda-lausekkeita. [10] Lähes samanlaisen toiminnallisuuden voi tehdä käyttämällä anonyymejä luokkia. Kuten yllä olevassa C#-esimerkissä, on myös Java-esimerkin count-metodi geneerinen eli samalla metodilla voitaisiin laskea esimerkiksi oliolistasta niiden olioiden lukumäärä, joiden attribuutit täyttävät halutun ehdon. C#:sta poiketen Javassa geneeriset tyypit voivat olla vain oliotyyppejä. [1]

interface Predicate<T> { public boolean apply(T type); }

public class AnonymousClassExample {
  public static <T> int count(T[] values, Predicate<T> predicate) {
    int amount = 0;
    for (T value : values) {
      if (predicate.apply(value)) {
        amount++;
      }
    }
    return amount;
  }

  public static void main(String[] args) {
    Integer[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
    int oddNumbers = count(numbers, new Predicate<Integer>() {
      public boolean apply(Integer number) {
        return number % 2 == 1;
      }
    });
    System.out.println(oddNumbers);
  }
}

4.9 Suoritusteho

Java ja C# ovat molemmat virtuaalikoneessa ajettavia kieliä. Tästä voisi nopeasti vetää johtopäätöksen, että molemmat ovat hitaampia C:hen ja C++:aan verrattuna, koska niillä kirjoitetut ohjelmat käännetään suoraan binäärikoodiksi. Tilanne ei kuitenkaan ole aivan niin yksinkertainen. Esimerkiksi IBM:n suorittamien testien perusteella Javan muistinvaraus on C++:n muistinvarausta nopeampaa, vaikka C++:ssa ohjelmoija voi päättää, varataanko tila keosta vai pinosta [9].

Vaikka korkeamman tason kielillä ohjelmoijan mahdollisuudet yksityiskohtaiseen suoritustehon virittelyyn ovatkin pienemmät, ei tämä ole välttämättä suora osoitus suoritustehon laskemisesta. C:täkin voitaisiin pitää Assemblyä hitaampana kielenä, koska C on välitaso ja ohjelmoijan kirjoittaessa suoraan Assembly-kieltä hän voi tehdä kaikki hyväksi toteamansa optimoinnit, joita kääntäjä ei osaa tehdä.

Kannattaa kuitenkin muistaa, että ohjelmien suoritustehovaatimukset vaihtele-vat ohjelmien luonteesta riippuen. Esimerkiksi verkkokauppaa tehdessä suuri osa käyttäjän kokemasta hitaudesta johtuu HTTP-yhteyksien hitaudesta ja tähän ei voi ohjelmointikielen valinnan vaikuttaa. Donald Knuth, eräs tietotekniikan alan suurista tutkijoista, on todennut ennenaikaisen optimoinnin olevan kaiken pahan alku ja juuri. Hän teki tämän väitteen jo vuonna 1974 [13].

Harvaa ohjelmaa kirjoitetaan tilanteessa, jossa aikaa ja rahaa olisi tarjolla loputtomasti. Jos rupeaa alusta asti kirjoittamaan käyttöliittymärutiineja C:llä tai jopa Assemblyllä, venyy kehitysaika varmasti Javaan ja C#:iin verrattuna, koska näille on tarjolla hyvin tehokkaita käyttöliittymäkirjastoja ja -työkaluja. Jos epäilee, että suoritusteho ei korkeamman tason kielillä välttämättä riitä, kannattaa kirjoittaa ensin prototyyppi korkeamman tason kielillä ja ajaa tämä kattavien suoritustehotestin läpi. Todennäköisesti pahimmassakin tapauksessa lisäsuoritustehoa vaativat ohjelman osat ovat pieni osa kokonaisuudesta. Nämä osat voidaan sitten optimoida esimerkiksi hiomalla algoritmit huippuunsa ja jos tarvetta oikeasti vielä tässä vaiheessa on, kirjoittaa ne uudestaan alemman tason kielillä ja liittää osaksi muuta ohjelmaa.

5. Yhteenveto

Maailmassa on valtava määrä ohjelmointikieliä. Eri ohjelmointikielet on suunniteltu erilaisia tarpeita varten. Vanhoja ohjelmointikieliä korvataan jatkuvasti uusilla. Vain yhden ohjelmointikielen osaaminen ei siis ole kannattavaa. Tutkimuksen tarkoituksena oli selvittää, voidaanko Java-ohjelmointikielen osaamista hyödyntää C#-ohjelmointikielen opiskelussa. Tutkimuksessa selvitettiin ohjelmointikielten yhtäläisyyksiä ja eroja ohjelmoijan näkökulmasta.

Yhtäläisyyksiä ja eroja selvitettiin vertaamalla etupäässä Microsoftin sekä aiemmin Sunin, mutta nykyään Oraclen tekemiä kielten ohjelmointioppaita, rajapintakuvauksia ja kielten teknisiä spesifikaatioita. Näiden lisäksi materiaalina käytettiin myös kolmansien osapuolten artikkeleita Javasta, C#:sta ja ohjelmoinnista yleisesti.

Tutkimuksen tulosten perusteella Javan osaamista voidaan käyttää hyvin C#:in opiskelussa. Molemmat kielet käyttävät olio-ohjelmoinnin paradigmaa, yhtälaista syntaksia ja virtuaalikonetta tavukoodin tulkitsemisessa käytettävän tietokoneen ymmärtämäksi konekoodiksi. Eroja kielten välillä ovat muun muassa C#:in käyttämät tietueet primiitimuuttujien kantaluokkana, virtuaalikoneiden saatavuus eri käyttöjärjestelmissä sekä C#:in tuki delegaateille ja lambda-lausekkeille.

Tutkimusten tulosten perusteella Javaa osaava ohjelmoija voi siirtyä helposti käyttämään C#:ia ja vastaavasti C#:ia osaava ohjelmoimaan Javaa. Tästä on hyötyä erityisesti yritysmaailmassa, jossa on tätä kirjoittaessa pula tietoteknologian osaajista Tietotekniikan liiton toiminnanjohtaja Robert Serénin mukaan [12]. Esimerkiksi C#-osaajaa etsivän yrityksen ei tarvitse tutkimusten tulosten mukaan hylätä Java-osaajaa, vaan hakija pystyy todennäköisesti omaksumaan uuden kielen nopeasti.

Voin vahvistaa tutkimusten tulosten pitävän paikkaansa omakohtaisten kokemuksieni perusteella. Keväällä 2010 vaihdoin Java-ohjelmointitehtävistä C#:ia käyttävään yritykseen. Siirtyminen tuntui helpolta ja se onnistui nopeasti.

Lähteet

[1] Allen, E., Diagnosing Java code: Java generics without the pain, Part 1, saatavilla WWW-muodossa, 1.3.2011.

[2] Byous, J., Java Technology: The Early Years, saatavilla WWW-muodossa, 24.1.2011.

[3] CNET News, Microsoft’s Holy War On Java, saatavilla WWW-muodossa, 23.9.2008.

[4] CNET News, Sun settles with Microsoft, announces layoffs, saatavilla WWW-muodossa, 7.12.2008.

[5] Codehaus Foundation, Groovy – An agile dynamic language for the Java Platform, saatavilla WWW-muodossa, 24.1.2011.

[6] Computer World, The A-Z Of Programming Languages: C#, saatavilla WWW-muodossa, 6.12.2008.

[7] DedaSys LLC, Programming Language Popularity, saatavilla WWW-muodossa, 25.1.2011.

[8] École Polytechnique Fédéralede Lausanne, The Scala Programming Language, saatavilla WWW-muodossa, 24.1.2011.

[9] IBM developerWorks, Java theory and practice: Urban performance legends, revisited, saatavilla WWW-muodossa, 18.1.2011.

[10] Java Community Process, JSR 335: Lambda Expressions for the JavaTM Pro- gramming Language, saatavilla WWW-muodossa, 1.3.2011.

[11] Jones, A. & Freeman, A., 2003. C# for Java Developers. Redmond, Washington: Microsoft Press.

[12] Kaleva, Oikeanlaisista it-osaajista ollut pulaa, saatavilla WWW-muodossa, 21.2.2011.

[13] Knuth, D.E., Structure Programming with go to Statements, saatavilla WWW-muodossa, 25.1.2011.

[14] Kurniawan B., Comparing C# and Java, saatavilla WWW-muodossa, 24.1.2011.

[15] Lämmel, R. & Jones, S.P., Scrap Your Boilerplate: A Practical Design Pattern for Generic Programming, saatavilla WWW-muodossa, 24.1.2011.

[16] Microsoft Developer Network, C# Language Specification, luku 7.5.2, saa- tavilla WWW-muodossa, 1.3.2011.

[17] Microsoft Developer Network, Enumerable.Count Method (IEnume- rable, Func), saatavilla WWW-muodossa, 1.3.2011.

[18] Microsoft Developer Network, Int32 Structure, saatavilla WWW-muodossa, 24.1.2011.

[19] Microsoft Developer Network, Lambda Expressions, saatavilla WWW-muodossa, 1.9.2009.

[20] Microsoft Developer Network, Overloadable Operators, saatavilla WWW-muodossa, 24.1.2011.

[21] Microsoft Developer Network, Pointer Types (C#), saatavilla WWW-muodossa, 3.9.2009.

[22] Microsoft Developer Network, struct (C#), saatavilla WWW-muodossa, 1.12.2008.

[23] Microsoft Developer Network, Type system unification, saatavilla WWW- muodossa, 7.1.2009.

[24] Mono Project, Mono, saatavilla WWW-muodossa, marraskuu 2008.

[25] SunWorld, Microsoft licenses Java, saatavilla WWW-muodossa, 2.5.2009.

PÄIVITYS: Nyt sivuillani on julkaistu myös kandidaatintutkielmani Javasta C#:iin.

Johdanto

Sain Vesa Lappalaiselta aiheeksi kandidaatintutkielmalleni Javan ja C#:in erojen selvittämisen. Koska tutkielman tarkoituksena oli kattaa suurin osa tavallisessa käytössä vastaan tulevista eroista, ei mihinkään yhteen tai muutamaan aiheeseen voinut tutustua erityisen tarkasti. Niinpä Ohjelmointikielten periaatteet -kurssin esseen aihetta miettiessä ajatukseni palasivat Javan ja C#:in pariin.

Esseessäni aion perehtyä neljään minua kiinnostavaan aiheeseen:

• Anonyymit funktiot ja delegaatit. Javassa lähes kaikki ovat olioita. Tästä johtuen yksittäisten funktioiden antaminen esimerkiksi järjestelijäoliollle ei onnistu suoraan, vaan funktio on paketoitava olion metodiksi. Miksi näin on? Onko tästä etua suoritusteholle, virtuaalikoneen toteutukselle vai onko kyse vain huonosta suunnittelusta?
• C#:in yhtenäinen tyyppijärjestelmä. Kaikki ovat C#:issa olioita: myöskin kokonais- ja liukuluvut. Javassa kokonaisluvuille on olemassa primitiivityyppi int ja oliotyyppi Integer. Tämä aiheuttaa ongelmaa esimerkiksi listoja käsitellessä, koska listat ottavat alkioikseen vain olioita, joten int-tyyppiset kokonaisluvut on paketoitava jälleen olion sisään. Miksi näin on? Häviääkö C#:in toteutusratkaisu Javalle nopeudessa?
• Operaattoreiden ylikuormitus. Javaan ei haluttu toteuttaa operaattoreiden ylikuormitusta C++:n kanssa ilmenneiden ongelmien takia. Oliko tämä pelko perusteltua? Ilmenevätkö C++:n ongelmat myös C#:ssa?
• Javassa poikkeuksia on kahdenlaisia: tarkistettavia ja ajonaikaisia. C#:ssa kaikki poikkeukset ovat ajonaikaisia. Mitä tämä tarkoittaa? Onko kahdenlaisista poikkeuksista hyötyä?

Tavoitteenani on, että tämä essee toimisi erinomaisena jatkoluettavana kandidaatintutkielmalleni niille, jotka haluavat perehtyä vielä tarkemmin kielten välisiin eroihin. Kandidaatintutkielma on pituudeltaan rajoitettu sellaiseksi, ettei kaikkia yksityiskohtia ole mielekästäkään käsitellä. Lisäksi käytän työelämässäni C#:ia, joten lisätutustuminen kyseiseen kieleen auttaa sekä akateemisia että työelämän tavoitteitani.

Delegaatit ja anonyymit funktiot

Anonyymit funktiot ovat funktioita, joille ei ole määritetty tunnistetta. Anonyymit funktiot eivät ole uusi keksintö, vaan Alonzo Church esitteli ne jo 1936 kehittäessään lambda-laskennan, jossa kaikki laskenta tehdään anonyymeillä funktioilla. Ohjelmointikielissä anonyymejä funktioita käytetään etenkin funktionaalisissa ohjelmointikielissä, mutta ne löytyvät myös esimerkiksi C#:ista ja JavaScriptistä. Java ei niitä tosin tue.

Ennen kuin perehdyn tarkemmin syihin, miksi C# tukee anonyymejä funktioita ja Java ei, on hyvä pysähtyä miettimään hetkeksi, miksi kukaan haluaisi käyttää anonyymejä funktioita moderneissa olio-ohjelmointikielissä. Esimerkiksi kokoelmien alkioiden suodattaminen ja järjestäminen on usein kätevää tehdä anonyymillä funktiolla. Javassa nykyisen käytännön mukaisesti järjestäminen muuhun kuin olioiden luonnolliseen järjestykseen hoidetaan tekemällä funktio-olio eli niin sanottu funktori, joka toteuttaa Comparator-rajapinnan vaatiman järjestysmetodin. Funktori annetaan edelleen staattiselle Collections.sort-metodille, joka lopulta hoitaa järjestämisen. Mielestäni tämä kuitenkin katkaisee ikävästi luontevan ohjelmointivauhdin ja pakottaa ohjelmoijan hyppäämään päässään toiselle abstraktiotasolle. Lisäksi mielestäni funktiot, jotka tekevät usean eri abstraktiotason tehtäviä, pyrkivät piilottamaan funktion varsinaisen tarkoituksen. Kyse ei ole siis vain tarpeettomasta kosmeettisesta kikkailusta, vaan anonyymeille funktioille pystyy mielestäni tekemään selkeästi luettavampaa ohjelmakoodia.

Javassa metodiin viittaminen ei onnistu, koska kaikki muuttujat ovat joko arvomuuttujia, jotka siis sisältävät suoraan esimerkiksi kokonaisluvun, tai viitemuuttujia, jotka voivat sisältää ainoastaan viitteitä olioihin, jotka ovat luokka-, rajapinta- tai taulukkotyyppisiä [1]. Suora viittaaminen metodiin ei siis ole mahdollinen. Alunperin Java 7 -versioon oli tarkoitus tuoda tuki anonyymeille funktioille, mutta tämän toteuttaminen lykättiin versioon 8 tai myöhempään [2].

C#:ssa viitemuuttujat voivat sisältää viitteitä olioihin, jotka ovat luokka-, rajapinta- tai delegaattityyppisiä. (Erillistä taulukkotyyppistä oliota ei C#:ssa ole, koska kaikki taulukot perivät yhteisestä abstraktista kantaluokasta System.Array [3].)

Delegaatti on viitetyyppi, joka voi viitata yhteen tai useampaan nimettyyn tai anonyymiin funktioon. Ne muistuttavat osittain C:n ja C++:n funktio-osoittimia, mutta niistä poiketen ne ovat tyyppiturvallisia. [4]

Jos ohjelmoija on käyttänyt pelkästään esimerkiksi Javaa, ei hän ole välttämättä osannut edes kaivata mitään tapaa viitata suoraan funktioihin tai esitellä niitä ilman anonyymin luokan vaatimaa byrokratiaa. Omasta mielestäni funktiot ovat kuitenkin erittäin tärkeitä yksiköitä ohjelman rakentamisessa ja niiden oliopaketoinnin vaatiminen Javassa johtaa ylimääräiseen byrokratiaan. Käsittelen Javan byrokratiaa ja sen vaikutuksia lisää yhteenvedossani.

Yhtenäinen tyyppijärjestelmä

Javassa muuttujatyypit voidaan luokitella kahteen ryhmään: arvo- ja viitemuuttujiin. Arvomuuttujiin kuuluvat boolean, char, byte, short, int, long, float ja double. Viitemuuttujat viittaavat olioihin, joiden nimet yleisen käytännön mukaan alkavat isolla alkukirjaimella: esimerkiksi String. Koska esimerkiksi kokoelmaoliot ovat kokoelmia toisista olioviitteistä, ei niihin voi sijoittaa arvomuuttujia suoraan. Siispä esimerkiksi kokonaisluvuillekin on oliovastine, Integer.

C#:ssa vastaavaa jakoa ei ole. Kaikki tyypit, myös arvotyypit, perivät object-kantaluokasta [5].

Miksi nämä kaksi samankaltaista kieltä eroavat? Äkkiseltään Javan toteutus kuulostaa tehokkaammalta. Olioiden luominen ei nimittäin ole kevyt operaatio, koska luodessa on laskettava olion tarvitsema tila, varattava muistista alue oliolle, sidottava olioon sen luokan ja mahdollisten kantaluokkien määrittelemät metodit, kutsuttava luokan ja mahdollisten kantaluokkien konstruktorimetodeja sekä luotava olioon osoittava viite. Arvomuuttujien kanssa riittää varata muistista vaadittu alue, jonka laskeminen on olion vaatiman tilan laskemiseen verrattuna triviaali, koska arvomuuttuja on vain yksi arvo, kun taas olion attribuuttien määrä joudutaan laskemaan. Lisäksi arvomuuttujan muistinkäyttö on huomattavasti pienempi. Jos ohjelmaa ajetaan 32-bittisessä käyttöjärjestelmässä, ovat myöskin olioviitteet 32-bittisiä, koska niillä pitää pystyä osoittamaan mihin päin muistiavaruutta tahansa. Siispä jos ohjelmassa käsitellään esimerkiksi 8-bittistä kokonaislukua 32-bittisessä käyttöjärjestelmässä, sen tallentaminen oliona vaatii 32 bittiä olioviitteelle, 8 bittiä varsinaiselle luvulle sekä kielestä ja olion luokasta riippuen jonkun verran lisämuistia olion muita tietoja varten. Arvomuuttujana 8-bittinen kokonaisluku sen sijaan vie vain 8 bittiä eli muistinkäytöltään kukin 8-bittinen arvomuuttuja on vähintäänkin 32 bittiä vaatimattomampi kuin vastaava kokonaislukuolio.

C#:n ratkaisu ongelmaan on matalammalla tasolla Javaa vastaavaa. Myös C# käsittelee kokonaislukuja sekä primitiiveinä että olioina. Erona Javaan on se, että C#:ssa muunnos näiden välillä tapahtuu käyttäjän huomaamatta tarpeen vaatiessa. Kun ohjelmassa esimerkiksi kokonaisluku annetaan argumentiksi metodille, joka hyväksyy object-tyyppisiä arvoja, kokonaisluku paketoidaan olioksi (engl. boxing).

Boxing- ja unboxing-toiminnot siis muuttavat arvomuuttujan oliomuuttujaksi ja takaisin. Sama löytyy myös Javasta. Erona kielten välillä on se, että Java tekee sekä boxingin että unboxingin tarpeen vaatiessa [6], kun taas C# paketoi arvomuuttujan oliomuuttujaksi implisiittisesti, mutta purkaminen takaisin arvomuuttujaksi tehdään eksplisiittisesti [7].

On tärkeää huomata, että jos boxing- tai unboxing-toimintoja käytetään vaativassa laskennassa, suoritusteho laskee valtavasti. Microsoftin mukaan erityisesti C#:lla ja yleisemmin kaikkien Common Language Runtimen päälle ajettavilla kielillä boxing-toiminto kestää 20 kertaa pidempään kuin viitemuuttujan asettaminen sekä unboxing-toiminto ja sen vaatima casting-operaatio kestävät 4 kertaa pidempään kuin arvon asettaminen arvomuuttujalle [8].

Suoritustehoa on yritetty paikata Javassa luomalla etukäteen joukko arvomuuttujien oliomuuttujia, jolloin boxing-operaatiot nopeutuvat huomattavasti, koska olioita ei tarvitse enää luoda tarpeen vaatiessa. Esimerkiksi boolean-arvot true ja false sekä kokonaisluvut väliltä [-128, 127] löytyvät valmiina [9]. Tästä johtuu muun muuassa minua kummastuttanut yksityiskohta, että kahden yllä mainitulta väliltä valitun kokonaislukuolion vertaaminen myös ==-operaattorilla pitää paikkaansa. Toki ==-operaattorilla ei Javassa suositella vertaamaankaan muita kuin primitiiviarvoja, mutta tämä saattaa aiheuttaa sekaannusta etenkin uusissa Java-ohjelmoijissa, jotka huomaavat tämän pitävän paikkaansa pienillä arvoilla, mutta jotka eivät huomaa testata samaa isommilla arvoilla.

Erityisen ongelmalliseksi Javan tyypit osoittautuvat tilanteessa, jossa tarvitaan ennalta tuntematon määrä kokonaislukuja tai muita arvomuuttujia. Tällöin suoritusteholtaan tehokkain ratkaisu on tallentaa arvot taulukkoon, jolle varataan jonkinlainen määrä muistia. Ongelmia ilmenee kuitenkin tilanteissa, joissa taulukon kokoa kasvatetaan, jolloin aiemman taulukon arvot joudutaan kopioimaan uuteen taulukkoon, joka on sopivan verran suurempi. Mikä sitten on sopiva määrä? Mahdotonta sanoa, koska tämä riippuu aina tilanteesta. Mielestäni tämä on jälleen yksi tilanne, missä Java-ohjelmoija joutuu miettimään ongelman ratkaisemista tasolla, jolle hänen ei tarvitsisi joutua.

Myös C#:issa on alunperin ollut ongelmia suoritustehon kanssa, jos arvomuuttujia on täytynyt tallentaa kokoelmiin (System.Collection-luokasta periviin olioihin). Tilanne kuitenkin muuttui C# 2.0:n julkaisussa, kun C#:iin lisättiin tuki geneerisyydelle. Jos arvomuuttujia tallennetaan System.List-luokasta periviin listoihin, ei boxing- ja unboxing-toiminnoille ole tarvetta arvomuuttujia listaan lisätessä tai niitä sieltä pois otettaessa [8]. Lisäksi geneerisyys on muutenkin suositeltavaa, jolloin ei joudu tukeutumaan cast-operaatioihin ja niistä mahdollisesti aiheutuviin poikkeuksiin, jos object-tyyppisestä kokoelmasta löytynyt olio ei ollutkaan alunperin peritty oikeasti luokasta.

Mielestäni C#:in yhtenäinen tyyppijärjestelmä on selkeä parannus Javan arvo- ja oliomuuttujiin jakamiseen verrattuna. Korkeamman tason ohjelmointikielten tavoitteena on nimenomaan vapauttaa ohjelmoija miettimästä yksityiskohtia, jotka tapahtuvat tarpeellista matalammalla abstraktiotasolla, jotta ohjelmoija voi keskittyä häntä oikeasti kiinnostavaan ongelmaan. Tietenkin abstraktiotasoissa voidaan mennä joissain tapauksissa liian pitkälle. Esimerkiksi jos kielessä ei olisi mitään mahdollisuutta tallentaa arvomuuttujia primitiiveinä, vaan kaikki tallennettaisiin olioina kuten esimerkiksi Python tekee, kärsii kyseisellä kielellä tehtyjen ohjelmien suoritusteho. Tällöin usein ohjelmoijan ainoaksi ratkaisuksi jää toteuttaa vaativa ohjelmaosuus jollain matalamman tason kielellä, jolla saadaan vaadittu suoritustehotaso. En väitä, että esimerkiksi Python olisi huono kieli, koska se näin tekee: Python on vain abstraktiotasoltaan vielä astetta Javaa ja C#:ia korkeammalla. Java ja C# sen sijaan toimivat samalla abstraktiotasolla, mutta Java pakottaa ohjelmoijan miettimään tyyppijärjestelmää mielestäni tarpeettoman matalalla tasolla muunnoskohdissa, joissa taas C# hoitaa muunnokset ilman ohjelmoijan panosta ja suoritustehoa laskematta.

Operaattoreiden ylikuormitus

Jo Javan kehityksen alkuvaiheissa päätettiin, ettei kieleen tule tukea operaattoreiden ylikuormitukselle, eikä kantaa olla muutettu kielen myöhemmissäkään versioissa. Kielen alkuperäinen kehittäjä James Gosling tosin myöntää jälkikäteen epäilevänsä ratkaisun pätevyyttä ja kertoo poisjättämisen syyksi hänen kohdallaan olleen huonot kokemukset C++-kielestä, jolla ohjelmoijat “väärinkäyttivät” operaattoreiden ylikuormitusta [10]. Myöskin comp.lang.java-uutisryhmän Usein kysytyt kysymykset -sivu listaa yhdeksi syyksi C++:n osoittaneen esimerkillään, että operaattoreiden ylikuormitus tekee ohjelmakoodista lähes ylläpitokelvotonta. Samainen vastaus mainitsee, että myöskään metodien ylikuormittaminen aiottiin jättää pois kielestä, mutta esimerkiksi tulostusmetodien kohdalla ylikuormittaminen auttoi niin paljon, ettei ominaisuutta lopulta jätetty pois. [11]

Väite on mielestäni erikoinen, koska esimerkiksi C#-yhteisöstä ei ole tullut vastustusta operaattoreiden ylikuormittamiselle eivätkä C#-kielellä tehdyt ohjelmat ole osoittautuneet ylläpitokelvottomiksi.

Javan kehittäjät väittivät, että kaiken, mitä operaattoreiden ylikuormituksella pystyy tekemään, pystyy aivan yhtä hyvin tekemään metodeilla ja attribuuteilla. Lisäksi operaattoreiden ylikuormittamisen poistaminen tekee koodista huomattavasti yksinkertaisempaa. [12] On totta, että teknisesti kaiken saman pystyy tekemään ilmankin ylikuormitusta. On myöskin totta, että esimerkiksi matriisiluokkia käsiteltäessä on huomattavasti yksinkertaisempaa kirjoittaa

result = (matrix1 + matrix2 - matrix3) * matrix4;

kuin

result = ((matrix1.sum(matrix2)).subtract(matrix3).multiply(matrix4);

Eräs usein kuulemani perustelu pelkillä metodeilla kirjoitetun koodin paremmuudelle on, että silloin metodin nimestä näkee suoraan, mitä metodi aikoo tehdä. Tämä ei kuitenkaan ole valitettavasti näin yksinkertaista. Hyvin usein metodeilla saattaa olla yllättäviä sivuvaikutuksia kuten esimerkiksi jostain lähteestä JDK:n BufferedReader-olion readLine-metodilla seuraava lukukohta siirtyykin luetun rivin verran eteenpäin [13]. Tämä ei todellakaan ilmene metodin nimestä, vaan ohjelmoijan on tiedettävä tämä muista lähteistä. Itse asiassa tämä ei ilmene myöskään metodin dokumentoinnista.

Kenties dokumentointi olisi hyvä kieltää kielen seuraavasta versiosta, koska se voi johtaa epäselviin tilanteisiin?

Javassa on valitettavan epäselvä tapa vertailla muuttujien samanarvoisuutta. Uuden ohjelmoijan aloittaessa Javan opettelun, näytetään hänelle usein esimerkkejä kokonaisluvuilla laskemisesta ja niiden vertailusta ==-operaattorilla. Olioiden kanssa kyseistä vertailua kuitenkin varoitetaan käyttämästä. Tämä johtuu siitä, että Javassa olioiden kanssa ==-operaattori vertaakin olioviitteiden samanarvoisuutta. Siispä esimerkiksi ohjelmakoodissa

String a = "merkkijono";
String b = "merkkijono";
bool vertailu = a == b;

vertailu saa arvokseen false. Tai ehkä true. Jos kääntäjä on huomannut, että kahta String-oliota yritetään luoda samalla merkkijonolla, se saattaakin luoda vain yhden String-olion, johon tässä tapauksessa sekä a- että b-muuttujat osoittavat. Jos halutaan vertailla olioiden yhtäsuuruutta, on käytettävä equals-metodia. Tämä yhtäsuuruusvertailujen tekeminen kahdella eri tavalla on mielestäni tarpeettoman monimutkaista ja on omien kokemuksieni perusteella johtanut lukuisiin virhetilanteisiin aloittelevien ja kokeneempienkin Java-koodaajien kohdalla. Aivot mieltävät olioidenkin vertailun ==-operaattorilla helposti oikeaksi toimenpiteeksi, koska pitäähän se paikkaansa myöskin primiitivien vertailun kohdalla.

Mielestäni Javan linja operaattoreiden ylikuormituksen kieltämiseen on paitsi perustelematonta myös tekopyhää. Mitenkäs Javassa yhdistetäänkään kaksi merkkijonoa yhteen? Aivan: "+" + "-" + "operaattorilla". Tässä tilanteessa +-operaattorin ylikuormittaminen onkin ollut hyvä idea, mutta ilmeisesti mitään muuta mahdollista tilannetta ei heidän mielestään ole.

Ymmärrän hyvin Javan kehittäjien alkuperäisen tavoitteen luoda kieli niin, että sillä olisi vaikeampi kirjoittaa epäselvää ohjelmakoodia. On totta, että on epäselvää, mitä esimerkiksi matriisiluokan ylikuormitettu bitshift-operaattori << tarkoittaisi? Kuitenkaan viisas ohjelmoija ei tällaista koskaan kirjoittaisi, jos se ei olisi mielekästä. On valitettava tosiasia, ettei ohjelmointikieli pysty suojelemaan ohjelmoijaa hänen omalta tyhmyydeltään Välillä ohjelmoijat tekevät virheitä ja epäselvällä operaattoreiden ylikuormittamisella saavat aikaan epäselvää ohjelmakoodia. Tämä kuitenkin pitää paikkaansa kaikilla kielillä – myös Javalla. Tehokkaan työkalun poistaminen kokonaan kielestä sen takia, että epäselvää koodia tuottavat ohjelmoijat voisivat tehdä sillä epäselvää koodia, on huono syy, koska samaisella työkalulla on lukuisissa tilanteissa osoitettu pystyvän tuottamaan luettavampaa ohjelmakoodia.

Poikkeukset

Ennen kuin tarkastelen enemmän poikkeuksia, puutun heti Javan poikkeusten nimeämiseen. Javan virallinen dokumentaatio jakaa poikkeukset tarkistettaviin (engl. checked) ja ajonaikaisiin (engl. runtime). Tämä on kuitenkin hämäävä tapa nimetä, koska eiväthän tarkistettavatkaan poikkeukset aiheudu muulloin kuin ajon aikana. Nimi juontaakin juurensa siihen, että käännön aikana voidaan huomata, mistä kohti tarkistettavia poikkeuksia voi aiheutua, kun taas ajonaikaisia poikkeuksia ei voida huomata etukäteen.

Olennaisin ero ohjelmoijalle tarkistettavien ja ajonaikaisten poikkeusten välillä on se, että kaikki metodin mahdolliset heittämät tarkistettavat poikkeukset on ilmoitettava metodin esittelyssä. Tarkistettavien poikkeuksien listauksessa on sekä hyviä että huonoja puolia. Hyvänä puolena on mielestäni se, että metodia käyttävät ohjelmoija tietää suoraan, mitä (tarkistettavia) poikkeuksia metodi voi heittää ja osaa varautua näihin joko käsittelemällä ne itse tai päästää ne oman kutsujametodinsa käsiteltäväksi. Huonona puolena on se, että kaikkien mahdollisten poikkeusten listaaminen on usein työlästä ja monitasoisessa ohjelmistoarkkitehtuurissa ylempien tasojen metodien poikkeuslistat venyvät helposti valtavan pitkiksi. Tästä johtuen tarkistettavia poikkeuksia käsiteltäessä onkin usein tapana paketoida ne omiin poikkeusolioihin, jolloin esimerkiksi asiakkaita käsittelevä CustomerRegister-olio voi heittää ainoastaan CustomerRegisterException-tyyppisiä poikkeuksia. Tämä johtaa kuitenkin siihen, että tasoja ylöspäin noustaessa oikeat poikkeukset saattavat löytyä todella monen erillisen poikkeusolion sisältä. Tällöin oikean ongelman löytäminen ja alempien tasojen vain tietynlaisiin poikkeuksiin reagointiin on hyvin työlästä.

Valitettavasti myöskin tarkistettavien poikkeusten hyvät puolet ovat täysin turhia, koska metodit voivat aina heittää ajonaikaisia poikkeuksia, joita ei ole pakko luetella metodin esittelyssä. Täten metodia käyttävä ohjelmoija osaa varautua vain osaan poikkeuksista, eikä hän voi koskaan täysin varmistua siitä, että kaikki mahdolliset poikkeukset olisivat hänen tiedossaan. Tämä johtaa omien kokemusteni perusteella kahdenlaisiin ongelmiin.

Ensimmäisenä ongelmana on se, että ohjelmoijalla jää valheellinen turvallisuuden tunne, kun reagoituaan tarkistettaviin poikkeuksiin hän kuvittelee poikkeustilanteiden olevan hallinnassa. Näin helposti unohdetaan kattavalla yksikkötestauksella tai muilla testaustyökaluilla varmistaa metodin toimiminen erilaisissa ongelmatilanteissa.

Toisena ongelmana on se, että ohjelmoija helposti varmistaa kaikkien poikkeusten käsittelyn ottamalla suoraan kiinni kaikki Exception-kantaluokasta perivät poikkeukset. Näin oikeat ongelmat kuitenkin jäävätkin alempien tasojen metodien syövereihin ja ylemmiltä tasoilta ongelmat ilmenevät vain ohjelmiston käsittämättömällä toiminnalla, jonka tunnistaminen ei tyypillisillä virheenkäsittelytavoilla onnistu mitenkään.

Omien kokemusten perusteella tarkistettavista poikkeuksista aiheutuvia haittoja paikataan usein paketoimalla kaikki mahdolliset poikkeukset ajonaikaisten poikkeusten kantaluokasta periviin poikkeusolioihin, jolloin niitä ei tarvitse enää esitellä kunkin metodin kohdalla.

Tiivistettynä siis Javan poikkeusjaottelut johtavat siihen, että kaikki tarkistettavat poikkeukset on ilmoitettava, jotta metodia käyttävä ohjelmoija osaisi niihin reagoida, mutta metodista saattaa lentää ajonaikaisia poikkeuksia, joista hän on onnellisen tietämätön. Eli siis byrokratiaa, joka ei lopulta ratkaise ongelmaa, vaan kannustaa ohjelmoijia huonoihin käytänteisiin.

C#:in kanssa poikkeuksia on ainoastaan yhdenlaisia eikä niitä tarvitse metodien esittelyssä listata. Aivan ongelmatonta ei ole toki tämäkään. Nyt ohjelmoijan tehtäväksi jää selvittää kaikki mahdolliset poikkeukset joko lukemalla metodin dokumentaatiota tai sen ollessa puutteellista, kirjoitettava kattavat automatisoitavat yksikkötestit tai muut vastaavat työkalut, joilla hän voi varmistua metodien odotetunlaisesta toiminnasta. Tämä kuitenkin on jo itsessään erittäin arvokasta ohjelmiston jatkokehityksen kannalta, joten poikkeusten esittelemättömyys ei sinänsä johdakaan huonompaan koodiin, vaan parempaan.

Yhteenveto

Jo kandidaatintutkielmaa kirjoittaessani huomasin, että Javan ja C#:in eroja vertaillessa en löytänyt mielestäni yhtäkään kohtaa, jossa Javan ratkaisu olisi osoittautunut paremmaksi. Näin kävi myös esseeseen valitsemieni erojen syitä selvitellessä.

Kenties on epäreilua vertaillakaan Javaa ja C#:ia näin suoraan, koska C# on tehty monta vuotta Javan jälkeen ja yksi sen suunnitteluun eniten vaikuttanut kieli onkin juuri Java. Täten C#:in kehittäjät ovat voineet katsoa, missä Java meni vikaan ja korjata ongelman. Javassa useat muutokset olisi vaikeaa tai jopa mahdotonta toteuttaa, koska kieli on ollut jo pidempään käytössä ja kaikki muutosehdotukset joutuvat tarkan kritiikin ja usein kovan muutosvastarinnan kohteeksi.

Mielestäni on ollut mielenkiintoista tutkia näiden kahden kielen eroja, koska sinänsä ne ovat niin lähellä toisiaan, mutta monissa yksityiskohdissa eroavat niin paljon toisistaan. Vertailujen aikana olen uudella tavalla oppinut arvostamaan kielensuunnittelun yksityiskohtien huomiota ja niiden vaikutusta kielellä toteuttaviin ohjelmistoihin pitkälläkin aikavälillä.

Olen työskennellyt molempien ohjelmointikielien kanssa. Javasta minulla on reilun kahden vuoden ja C#:ista noin kahdeksan kuukauden ammatillinen kokemus. Työskennellessäni Javan kanssa huomasin lähes päivittäin, miten kieli osoittautui työtä hidastavaksi tekijäksi. Pahimmillaan kielen puutteet tekivät joistain ratkaisuista todella vaikeita toteuttaa, mutta parhaimmillaankin ongelmat tekivät ohjelmakoodin kirjoittamisesta vähemmän mielekästä. Lisäksi huomasin oman luovuteni ja inspiraationi kärsivän joutuessani käyttämään työkalua, joka niin monesta kohdasta tuntui kankealta ja mielikuvituksettomalta. C#:in kanssa en ole huomannut vielä kertaakaan miettiväni, miten helppoa ohjelman toteuttaminen olisi toisella kielellä. Tämä on parantanut huomattavasti työmotivaatiotani. Onkin hyvä muistaa, että ohjelmakielten puutteet eivät aiheuta vain teknisiä, vaan myös henkisiä ongelmia.

Lähteet

[1] Sun Microsystems Inc., Java Language Specification, 3rd Edition, haettu 22.11.2010.

[2] Oracle Corporation, JDK 7 Features, haettu 22.11.2010.

[3] Microsoft Corporation, Arrays Tutorial, haettu 22.11.2010.

[4] Microsoft Corporation, Using Delegates (C# Programming Guide), haettu 22.11.2010.

[5] Microsoft Corporation, Type System Unification, haettu 23.11.2010.

[6] Oracle Corporation, Autoboxing, haettu 23.11.2010.

[7] Microsoft Corporation, Boxing and Unboxing, haettu 23.11.2010.

[8] Microsoft Corporation, Performance, haettu 23.11.2010.

[9] Sun Microsystems, Conversions and Promotions, haettu 23.11.2010.

[10] The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling, haettu 23.11.2010.

[11] The comp.lang.java FAQ List, haettu 23.11.2010.

[12] The Java Language Environment, haettu 23.11.2010.

[13] BufferedReader (Java 2 Platform SE 5.0), haettu 23.11.2010.

Astetta mielenkiintoisempi laite oli hieman myöhemmin kuvioihin tullut videokamera. Sen kanssa ei ollut kehitysongelmia, vaan lopputuloksen pystyi katsomaan välittömästi TV-ruudulta. Tällä tulikin kuvattua kavereiden kanssa paljon erilaisia lyhytelokuvia. Dialogi ja näyttelytyö aiheuttaisivat varmastikin nyt katsottuna päänsärkyä, mutta jo pienenä osasi kiinnittää huomiota kohtausjärjestyksiin ja erikoistehosteisiin. Tyynyillä täytetyt vanhat vaatteet toimivat hyvin stunttinukkena, jonka pystyi heittämään parvekkeelta. Valitettavasti videoiden leikkauksesta ei ollut mitään käsitystä, vaikka kaverilla olikin käytettävissä kahdet videot, joten tekniikka olisi periaatteessa ollut käytettävissä. Tästä johtuen elokuvat oli kuvattava kronologisessa järjestyksessä ja liikuttava edestakaisin kuvauspaikkojen välillä. Videokuvausharrastus lakkasi lopulta yllättäen, kun erään elokuvan kuvauksissa kamera yllättäen lopetti toimintansa. Idea videokuvauksesta tulevaisuudessa jäi kuitenkin kytemään.

Kaikenlaiset kuvausharrastukset jäivät pitkälle tauolle. Perheestä ei löytynyt mielenkiintoa herättäviä kameroita ja ala-asteikäisenä ei ollut varaa sellaista itsekään hankkia. Yläasteella rahaa kuitenkin rupesi siunautumaan etenkin rippikoulun jäljiltä ja päätin sijoittaa rahani Canon Ixus V -kameraan.

Olin aiemmin kokeillut muutamaa levykettä muistinaan käyttävää kameraa, mutta levykkeiden virhesietoisuudella lähes joka viides kuva tuntui korruptoituvan ja levykeasema kasvatti kameran koonkin valitettavan isoksi. Lisäksi levykkeelle ei kovin montaa kuvaa mahtunut, vaikka megapikseleitä ei vielä laskettukaan monikossa. Ixus V:ssä ei ollut levykeasemaa aiheuttamassa murheita, vaan kuvat tallentuivat CompactFlash-korteille. Kun mukana tulleen 8 megan kortin vielä korvasi (aikanaan) valtavalla 64 megan kortilla, mahtui kuvia kerralla jo lähemmäs sata. Kun oli tottunut 24 kuvan filmirulliin, joiden kehittäminen kesti ikuisuuksia, tällainen kamera tuntui valtavalta harppaukselta kehityksessä. Pienen kokonsa ansiosta kamera kiersikin mukana monta vuotta ja sillä otettiin varmastikin yli 10 000 kuvaa. Kuvasimmepa ystävien kanssa myös Lego-animaation, jotka 2000-luvun alkupuolella olivat kuumaa hottia:

Ylläoleva video on muuten kerännyt YouTubessa yhteensä vajaa 90 000 katsomiskertaa*. Tällainen katsojamäärä yläasteikäisten yhden illan projektille on jotain sellaista, mitä ei ennen Internetin aikakautta olisi voinut kuvitellakaan. Tästä lisää joskus myöhemmin.

*) Katsomiskerrat ovat jakautuneet kahdelle eri videolle.

Sanotaan, että on harrastettava jotain aihetta 10 000 tuntia tullakseen siinä todella hyväksi. Valitettavasti sääntö tuntuu pitävän paikkaansa myös valokuvauksen saralla ja vain 10 000 kuvan ottaminen ei välttämättä tuo vielä osaamista. Pikku hiljaa kuviin kuvatessa rupesin kiinnittämään huomiota muuhunkin kuin että osasi vain osoittaa kameran suurinpiirtein kohti kohdetta. Erityisesti minua kiinnostivat jo tässä vaiheessa syväterävyydellä leikittelevät ja pimeässä otetut kuvat. Näiden ottaminen ei Ixus V:llä oikein onnistunut, vaikka muutama aikanaan mielestäni hienokin kuva tuli napattua.

Jostain syystä vuonna 2007 valokuvaus rupesi kiinnostamaan uudestaan ja markkinoilta löytyikin mieleinen uusi kamera, Canon Ixus 850 IS. Kameran kuvanvakaaja ja yli sekunnin valotusajat auttoivat kummasti pimeäkuvauksen kanssa. Lisäksi samaan aikaan innostuin myös matkailusta ja kamera onkin kiertänyt ostamisensa jälkeen kymmeniä tuhansia kilometrejä matkassani. Edelleenkin kameraa tulee käytettyä tilanteissa, joihin järjestelmäkameran kantaminen olisi liian raskasta tai joissa järjestelmäkameran koko säikäyttäisi kuvauskohteen.

Yöpilvet Jyväsjärven yllä

Belfastin kaupungintalo

Kun rupesin saamaan hienompia kuvia aikaiseksi, alkoi kameran pokkarimaisuus rasittamaan. Käytännössä tämä ilmeni niin, että monet asetukset piti seikkailla kankeiden valikoiden takaa. Olipa laukaisinpainikkeen herkkyydessäkin pienoisia ongelmia ja pari hienoa tilannekuvaa menivät ohi suun minun ja painikkeen ollessa eri mieltä painalluksen tapahtumisesta.

Kenties tärkeimpänä oli kuitenkin pokkarin kennon koko. Pienellä kennolla ei saa yhtä intiimiä syväterävyyttä kuin järjestelmäkameralla, jos ei ota aivan lähikuvaa niin sanotulla kukka-asetuksella. Aiemmin digitaaliset järjestelmäkamerat olivat maksaneet aivan älyttömästi ja siten jääneet haaveiluidenkin tavoittamattomiin, mutta Canonin EOS D -sarja oli tuonut markkinoille monta kuluttajille suunnattua järjestelmäkameraa, joiden hintalappu oli alle 1000 euron luokassa. Kun samalla pääsin ensimmäistä kertaa oman alan työpaikkaan, oli päätös järjestelmäkameran ostamisesta helppo.

En ollut ennen oman järkkärin käsittelyä tehnyt kuin muutaman nopean kokeilun tuttujen kameroilla ja kuvittelin, että kuvan ottaminen järkkärillä olisi samanlaista kuin pokkarilla, mutta kuvista tulisi vain jotenkin automaattisesti parempia. Tämä ei kuitenkaan pitänyt paikkaansa. Pokkarilla kuvista tuli lähes poikkeuksetta teräviä, jos vain valoa oli kylliksi. Järkkäreillä isomman kennon myötä tuleva syväterävyys johtaa siihen, että juuri haluttu kuvauskohde on pidettävä tarkkana, koska usein koko kuva ei olekaan enää tarkkana. Tätä ominaisuuttahan olin järkkäriä ostaessa hakenutkin, mutta kuten niin monet muutkin asiat valokuvauksessa, myös tämän takia joutui uhraamaan jostain toisaalta. Automaattitarkennuksella tätä tehtävää voi toki hieman helpottaa, mutta se valitsee usein etualalla olevat kuvat tarkennettaviksi. Alla hieno esimerkki siitä, miten väärään kohteeseen osunut tarkennus muuttaa kuvan luonteen täysin:

Elämä järjestelmäkameran kanssa alkoi hieman kivikkoisesti ja hetkellisesti kuvausinto laantuikin uutuuden viehätyksestä huolimatta, kun kuvaaminen tuntui vaikealta. Askel askeleelta opin kuitenkin ajattelemaan kuvausta syvemmällä tasolla ja miettimään uudella tavalla aukkoja, valotusaikoja ja polttovälejä. Samalla myöskin kuvat paranivat. Tämä ei kuitenkaan ollut helppoa tai nopeaa, vaan vasta nyt kaksi vuotta järkkärin ostamisen jälkeen rupeaa tuntumaan siltä, että osaan jotakuinkin käyttää sitä. Valitettavasti pelkkä tekniikan osaaminen ei tosin riitä, mutta sen hallitseminen vapauttaa taas ajattelun miettimään korkeamman tason asioita.

Itsenäisyyspäivän viettoa Bostonissa

Japanissa

Uudet objektiivit kameran mukana tulleen lisäksi ovat avanneet uusia mahdollisuuksia niin läheltä kuin kaukaakin. Ostoslistalla onkin jo varmaan tuhannen euron edestä muutama objektiivi, joilla pääsee kuvaamaan entistä kauempaa tai entistä pimeämmässä. Kaiken ostohuuman keskellä on kuitenkin muistettava, että oikea valokuvaus ei ole välineharrastus, vaan hyvä valokuvaaja ottaa kuvan kameralla kuin kameralla. Ennen kaikkea on vain otettava paljon kuvia. Olen myöskin huomannut hyväksi tavaksi omien kuvien tarkan arvioinnin. Muun muassa tästä syystä olenkin täyttänyt asuntoni seinät itse otetuilla kuvilla, jotta aiempien kuvien onnistumiset ja virheet painuvat mieleen.

Tiikerin päiväunet turvallisen etäisyyden päästä

Järkkärin kanssa kuvaillessa vierähtikin mukavasti tovi jos toinenkin. Tänä aikana teräväpiirtovideokamerat olivat kavalasti valloittaneet videokameramarkkinat ja niiden hintakin oli laskenut taas kuluttajatasolle. Vanha viehätys videokuvaukseen heräsi uudestaan, kun lomamatka Yhdysvaltojen itärannikolle rupesi häämöttämään suunnitelmissa. Mieli oli tehnyt jo pitkään päästä Yhdysvaltoihin, eikä tällaista reissua voinut jättää vain valokuvien muistettavaksi. Säästöjäkin oli kertynyt niin mukavasti, että Canon Legria HF200 -kameran hankkiminen ennen reissua ei pakottanut syömään matkalla pelkkää purkkitonnikalaa.

Vaikka olinkin teräväpiirtokuvaan tottunut jo Internetin myötä, oli kavereiden ja minunkin näkeminen teräväpiirtona yllättävä kokemus. Vanhoihin kasettivideokameroihin ei kuvanlaatua voinut oikein edes verrata. Vaikka aivan filmitasolle ei vielä päästykään, oli lopputulos mielestäni jo sellaista, ettei katsoessa muistanut koko ajan katsovansa “vain” kotivideota.

Nauhakameroilla nauha jouduttiin kuvaamaan alusta loppuun ja jos väliin jäi jotain turhaa, jonka olisi halunnut poistaa, olisi ainoana mahdollisuutena olla kuvata jotain uutta päälle. Tämä kuitenkin johti herkästi siihen, että uusi video meni vanhan onnistuneenkin päälle. Muistikortteja käyttävillä kameroilla tämä ei ole ongelma, vaan kohtaukset voi poistaa kätevästi yksi kerrallaan ja kortilla mahtuu edelleenkin saman verran kuin jos sen olisi täyttänyt järjestyksessä.

Usein videoita kuvatessa tulee kuvattua kaikenlaista ylimääräistäkin, joka kuvaushetkellä saattaa vaikuttaa hyvältä. Myöskin tiettyjä tilanteita odottaessa kameran antaa varmuuden vuoksi pyöriä tyhjää, jotta se hieno hetkikin tallentuisi muistiin. Näitä ei kuitenkaan jaksa katsoa itsekään saati sitten ulkopuoliset katsojat. Siispä videoita kannattaa leikata. Muistikorttipohjaisten kameroiden kanssa tämä oli helppoa: muistikortti koneelle, ohjelmasta import-toiminto päälle ja hetken odottelun jälkeen video oli valmiina leikattavaksi. Mac-koneiden mukana tuleva iMovie-ohjelmisto osoittautui varsin näppäräksi työkaluksi, jonka käytettävyys oli niin hyvä, että pystyi keskittymään vain lopputuloksen miettimiseen, eikä aikaa tuhrautunut ohjelmiston kanssa tappeluun.

The United States Of America -kirjoituksestani löytyy esimerkki siitä, millaista lomavideota Yhdysvalloista sain uuden kameran ja leikkausohjelmani kanssa. Myöskin Japanin matkaltani on tulossa vastaava video, kunhan saan pitkän leikkausoperaationi valmiiksi.

Tässä vaiheessa olin päässyt jo lähes niihin tavoitteisiin, mistä lapsena olinkin haaveillut. Vielä oli kuitenkin yksi tärkeä askel: vaikka video olikin teräväpiirtoa, näytti se kuitenkin edelleen videolta eikä Hollywood-elokuvalta. Tekniikka tarjosi lopulta avun myös tähän. Uusimmat järjestelmäkamerat saivat teräväpiirtovideokuvauksen lisäominaisuudekseen. Olennaisena erona järkkärillä ja videokameralla kuvatessa ovat samat tekijät kuin pokkarilla ja järkkärillä valokuvia ottaessa: iso kenno mahdollistaa syvyysterävyydellä kikkailun ja paremman pimeäkuvauksen sekä vaihdettavat objektiivit auttavat kameran muuntamisen kuhunkin kuvaustilanteeseen paremmin sopivaksi. Canon EOS 550D oli Canon-merkkiuskolliselle kuvaajalle ensimmäinen järkevän hintainen kamera. Se päätyikin ostoskoriin lähes heräteostoksena, kun Alternative Party 2010 -tapahtuman vierestä löytyi Verkkokauppa.comin myymälä ja säästötilillä poltteli useampi ylimääräinen satanen.

Uusi kamera on ollut käytössäni vasta reilun kuukauden, joten en ole vielä päässyt mielestäni kunnolla perehtymään sen käyttöön. Käsin tarkentaminen liikkuvan kuvan kanssa on vielä valokuvien tarkentamistakin haastavampaa. Elokuvia kuvatessa tämä homma onkin usein ulkoistettu erilliselle tarkentajalle (focus puller), jolloin kuvaaja pystyy keskittymään kuvan rajaamiseen ja kameran sijoitteluun.

Kuten kirjoituksesta varmasti huomaakin, on kuvaaminen päässyt hyvinkin lähelle sydäntäni. Jatkossa on siis varmasti luvassa lisää kirjoituksia aiheesta. Tästä loppuun vielä esimerkki siitä, millaista videokuvaa olen tähän mennessä uudella järkkärilläni saanut aikaan: