Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

ICFP 2002 Contest Winners Announced 254

Posted by timothy from the coffee-bean-laurels-would-be-appropriate dept.
Georgwe Russell writes "The Winners have been announced at the official web site. Looks like OCaml and functional programming have won again, with the 3 member TAPLAS team. There is somewhat of an upset, though. Second place goes to 3-member team Radical TOO, whose entry was written in C! In the lightning round, the virtues of Python as a quick prototyping language were shown in the lightning division's winning entry by the OaSys one-man team. Does the skill of the programmer prevail over the limitations of the language and paradigm used, or is C nearly as good a language as OCaml?"
This discussion has been archived. No new comments can be posted.

ICFP 2002 Contest Winners Announced More

ICFP 2002 Contest Winners Announced

Comments Filter:

  • Yeah.. language is not matter much.. (Score:5, Interesting)

    by WetCat ( 558132 ) on Saturday October 05, 2002 @09:36PM (#4395253)
    The proficiency in writing programs means more.
    Most languages are functionally equivalent,
    you can even have something like Alma [memoire.com]:
    a program that translate a lot languages to a lot of other languages. It's fun to play with it!
    • There's always been a big divide between functional and imperatie languages.
      C is imperative, you have to tell the computer exactly what to do. OCaml is functional, you give the computer rules and then point it in the right direction. I don't believe alma will convert from one group to the other.
      People who rate functional languages always site impressive examples like the guy who wrote a submarine control program in 40 lines of ML, where previously it was 40,000 lines of C.
      The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.
      In this time-boxed challenge, I'm not surprised to see C come in as one of the winning entries. I think that if the time constraints were relaxed, though, you'd see nothing but OCaml, Gofer, ML etc etc.
      • It's funny, but alma DOES that. It can convert C++ and/or Java and some other languages to C (and some other not object oriented languages).
        You can experiment with Alma here [desnoix.com]
        (Disclaimer: I am not sure that it can hold /. effect...)

      • Re:Language doesn't matter, language CLASS matters (Score:5, Informative)

        by jbrandon ( 603700 ) on Saturday October 05, 2002 @10:32PM (#4395404)
        OCaml is functional, you give the computer rules and then point it in the right direction.

        That's not what "functional language" means. The magic of functional programming comes from the (sometimes typed) lambda calculus, in which functions can be passed as parameters. In this vein, we also have easier polymorphism (functions can take a type as a parameter) and fewer "side effects," which could mean fewer bugs.

        See Why Functional Programming Matters [chalmers.se]. For the theoretically inclined, I enjoyed An Introduction to Polymorphic Lambda Calculus with Subtyping [vub.ac.be].

        (Both links can be found on the pages I link to; I don't link to the articles because I don't know your document format of choice.)
        • There's a lot more to it than that. Recursive type definition and lazy evaluation are the two big-ticket items that spring to mind.
          I guess to people who know, my description sounds more like prolog than fp, but i still think it's a better way of describing to someone who's never seen a functional langauge before.
          • Most of the well-known functional languages don't do lazy evaluation, so that would only be a "big ticket item" for languages like Haskell, which do.

            And no, I don't think your description captured functional languages very well - as you say, it sounded more like Prolog. Besides, the "rule-based" appearance of some functional languages (notably Haskell & the ML family) is really mostly syntactic sugar. Scheme, which is much closer to the pure lambda calculus on which most functional languages are based, doesn't have such a rule-based appearance.

      • Are you sure you don't have it backward? (Score:5, Informative)

        by tmoertel ( 38456 ) on Saturday October 05, 2002 @11:18PM (#4395522) Homepage Journal
        The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.
        Are you sure you don't have it backward about the amount of time it takes to write software in functional languages? Most of the people I know who are good programmers of both functional and imperative languages consider the former to be considerably more efficient when it comes to programmer time. My experience with functional vs. imperative languages has certainly shown this to be the case. Likewise, industry groups that have made investments in functional programming have found significant increases in programmer productivity.

        But don't take my word for it:

        • Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) [nec.com] Abstract: We describe the transformation of XVision, a large library of C++ code for real-time vision processing, into FVision (pronounced "fission"), a fully-featured domain-specific language embedded in Haskell. The resulting prototype system substantiates the claims of increased modularity, effective code reuse, and rapid prototyping that characterize the DSL approach to system design....
        • Four-fold Increase in Productivity and Quality: Industrial-Strength Functional Programming in Telecom-Class Products [erlang.se] (PDF) Abstract: The AXD 301 ATM Switch is the flagship in Ericsson's line of Datacom products. A fault tolerant and highly scalable backbone ATM switch, AXD 301 has enabled Ericsson to take the lead in the migration of public telephony networks to becoming true multiservice networks, offering both quality voice and broadband data services on the same backbone.... This paper demonstrates how the development of such systems is supported by the Erlang/OTP technology. The Erlang [functional] programming language was developed by Ericsson specifically for the purpose of building fault tolerant, distributed and complex systems.... The paper demonstrates how Erlang supports the characteristics mentioned, while offering unusually high productivity.
        • Haskell vs. Ada vs. C++ vs. Awk vs. ... : An Experiment in Software Prototyping Productivity [chalmers.se]: Abstract: We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.
        • Functional languages in microcode compilers [acm.org] (ACM Digital Library). Abstract: This paper discusses the advantages of using high-level languages in the development of microcode. It also describes reasons functional programming languages should be considered as the source language for microcode compilers. The emergence of parallel execution in microarchitectures dictates that parallelism must be extracted from the microcode programs. This paper shows how functional languages meet the needs of microprogrammers by allowing them to express their algorithms in natural ways while allowing the microcode compiler to extract the parallelism from the program.
        You can find more such papers by tracing references and by reasonable application of Google and CiteSeer.
        • Well, you point to :

          - one situation in which the language was specifically written for the task at hand. I give you the fact that you get a productivity enhancement if your language is tailored to your problem (probably regardless of whether it's functional or not).

          - one situation which doesn't mention the speed to code at all (the microcode one)

          - 2 different 'prototype' experiments.

          In case you missed it first time around,
          The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.
          Prototype != working code. Case made.
      • If these functional languages can be compiled or even just run, then obviously they can be converted to imperative languages.

        If the programs couldn't be run on imperative machines, what would be the point in writing programs in 'em.
        • Yes, thank you Mr Turing. The fact that it can be done doesn't mean it'll make sense to anyone but the computer, and it definitely doesn't mean it should be done :)
        • actually an old colleague of mine had the opinion that functional languages weren't _inherently_ more productive, but _did_ tend to attract programmers who understood abstraction at a deep level.

          these guys can write good code in _any_ language (he was a scheme hacker who was busy optimising HAIRY C gc code), but are attracted to functional langs because such langs directly capture the abstractions these guys use.

          so, to paint with a broad brush, functional languages aren't nec. better than imperative, but the functional paradigm (abstraction, genericity, focussing on data rather than process) IS.
    • Language doesnt matter??? Then lets institute Brainfuck only programming challenges. ... then again, maybe not ^_^
    • The proficiency in writing programs means more. Most languages are functionally equivalent,

      Languages like C, C++, Java, C#, Ada, Eiffel, VisualBasic, etc., are indeed largely interchangeable, and you can all approach them with the same mainstream object-oriented design methodology.

      But just because you are a proficient Java or Eiffel programmer and object-oriented designer doesn't mean that you have a clue about how to write effective code in a functional programming language. You can design functional programs like object-oriented programs, and the result will work, but it will be as tedious as if you had written the code in an object-oriented language to begin with.

      To take advantage of functional languages (or, more generally, other non-object-oriented languages), you have to unlearn pretty much everything you learned about object-oriented design.

      It's quite analogous to the procedural/object-oriented transition: lots of people believed that they could write object oriented code because their procedural coding styles kind of kept working, but they were missing the point. You are missing the point, too, if you think that functional programming is just a small variation of what you are already doing.

      Furthermore, functional programming is very hard to simulate well in object-oriented languages--most attempts end up not being able to provide the invariants and encapsulation that functional programming guarantees automatically, and without the type systems of functional programming languages, many interesting usages are just too complex to type.

  • What's wrong with C? (Score:2, Informative)

    by Anonymous Coward
    I wasn't aware that C was no longer a good language...

    • Re:What's wrong with C? (Score:4, Informative)

      by Gekko ( 45112 ) on Saturday October 05, 2002 @10:00PM (#4395310)
      The contest was a fast prototyping contest. You had 72 hours to complete the contest. Ocaml's strong type checking and garbage collection can make a big difference.

      Of course an excellent C programmer, with excellent tools can prototype fast, but they have to have more domain knowledge and a more intimate understanding of their language.

      From the contest web site.
      "correctness, algorithmic cleverness, and performance will matter"
      • Indeed, C's strength comes form the large number of extremely experienced programmers who've been doing it for years and years.

        Better to go with what you know than waste time on the stilted syntax of some crazy moonman language that could theoretically do it with less typing.

  • It's the Algorithm, Stupid (Score:5, Insightful)

    by null-und-eins ( 162254 ) on Saturday October 05, 2002 @09:41PM (#4395261) Homepage
    This year's ICFP task, as well as last years, was all about finding a good algorithm. More than anything else, knowing the domain would help. Of course, using a language that provides strong typechecking (like OCaml) or garbage collection (OCaml, Python) allows a programmer to concentrate on the main task. You should not draw too many conclusions from the language that was used for the winning entries.
    • Of course, using a language that provides strong typechecking ... allows a programmer to concentrate on the main task.

      That is flamebait horse shit! There is no clear evidence that strong typechecking "allows programmer to focus" more.

      IMO, it is subjective. Different people work better under different language concepts. What F's Joe up may not F Jenny up, etc. I have seen many 100+ message debates on this topic, and there is no objective victory for either side of the typing debate. I just know what works better for me. I grew up on strong-typed languages, but now prefer dynamic or type-free languages.

  • I guess I'm not a real geek afterall (Score:4, Funny)

    by mao che minh ( 611166 ) on Saturday October 05, 2002 @09:46PM (#4395274) Journal
    I have no clue what the hell any of this is about.

  • What about #3-160? (Score:3, Informative)

    by spRed ( 28066 ) on Saturday October 05, 2002 @09:53PM (#4395288)
    Shamefull vanity, but I'd like to know how I did.
    Radical Too (runner-up) was kind enough to post their source (after the competition is over, there isn't much reason not to).

    But what about me (Aqua Team Hunger Farce)?

    Links to source/explanations of many entries can be found on the ICFP site Here [ogi.edu]

    My entry is listed as well. The order of listing is just when people submitted links to writeups, not the winning order.
  • I learned OCaml when I had pneumonia, so I had a lot of time to play with it. It seems like languages are like keyboard layouts. Just as in any other language, the more you can "Think" in that language, the faster and better you can write programs. But for OCaml, there seems to be a higher limit to the writing proficiency than in C, a language I have worked in for many years. It's a bit like the Dvorak keyboard versus the Querty keyboard.

  • C is a gr34t langu4g3! P1eese k33p u5ing it!!! (Score:3, Interesting)

    by Anonymous Coward on Saturday October 05, 2002 @10:24PM (#4395381)
    We love the way C makes you think about all those little details like strings and bufsize and pointer math. It means we get to keep 0wning you, because you can't get it right.

    Don't get me wrong; C is great for the kernel and other code that needs to be machine-layer portable. But with the gnome panel at 5 mb, apparently no one cares about writing tight code anymore. So if its not going to be small and fast, it might as well be secure and reliable.

    Which C will never be.
    • What operating system and languages do you use? I bet they are implemented in C. If C isn't secure and reliable how can applications programmed in higher level languages built on them be secure and reliable?

      -Kevin

      • Yeah, most OS's are implemented in C, and that's a big portion of why they aren't secure nor reliable in most cases. C doesn't have garbage collection by default, and therefore there are buffer overflows found in virtually every C program. It doesn't show up as much in a kernel just because of the way that they work. It's not a big deal really, but remember you are trusting all your files to the programmers abilities if you install a C program more than say if you are installing a Java or python app.
        • The language in which the compilers and interpreters for those garbage collecting, so called, secure languages are written is most likely C. Is C the best language, probably not, and which language is best depends on both the task at hand, and the programmers preferences and abilities. The same can be said for any other language. So just remember your roots before you start dissin'...

          • Actually, the system of which you speak is called a microkernel. People complain about context switches when you mention micro-kernels, but there are several good performing microkernels in use today. The way I see it is you had to switch context at some point anyhow :)

            It does depend on the skill of the programmer... that's my point. You are trusting more people than you realize to have written good software that could intentionally or accidentally compromise your precious data.

            Java and other GC languages aren't magical, they don't remove buffers. All they do is what any decent system should: check the buffers in system code. You're not going to break Java programs just because they are running on something that was written in C, because the checks are done and tested.

            Not many people argue that we should still be using assembler. The shift is clear. It began with C taking over the app market, then all of a sudden a bunch of freaky students decided they wanted to write an OS for gaming, and they didn't want to bother with all that low-level assembler crap. I really don't see C living much longer as a popular language. Laugh now, but it happened before, and history repeats itself, and for good reason this time. I wouldn't be suprised if cracking and terrorism speed it up.

            The most likely place where you'll start seeing Java (only because it's the most developed and easy to use of the GC languages) programs crop up are everything from shells to window managers. Then the server processes will be taken over by Java counterparts. A Java DNS server and a Java MTA will be made by someone tired of being hacked every other week through bind and sendmail. It will be easy to administrate because it will have a nice GUI. Then the hackers will pick on another C project.
        • C is used because it allows you to access system resources directly. You must do this to have a perfomant system. It doesn't matter if the language is C specifially, it just happens to be the most succesful systems language.

          One day an operating system will be implemented as a set of APIs on a VM consisting of a very small set of machine-dependent code, but not yet.

          • C is used because it allows you to access system resources directly.
            However, it is entirely possible to have a language that is both type-safe AND allows direct access to system resources. Modula 3 and Ada come to mind, but there are others.

            If more software were written in type-safe languages, we wouldn't have so damn many buffer overrun security holes popping up all the time. It's possible to write secure software in C, but the language doesn't help you do it. C isn't a high-level language, it's a portable assembler. Writing large pieces of software in C is madness.

      • but besides that, the core of the OS dosn't need to be very big, so you really can check everything.

        A huge program in C++ will probably have tons of buffer overflows to exploit. A Large Java program will have ZERO overflows.

        It's like comparing a hand grenade to an orange. Both can be handled safely, but an orange is just not going to blow up, no matter what you do, while the hand grenade has an increasing chance of exploding the more you fiddle with it.
      • No, no, no. It's easier to implement a compiler or runtime environment which guarantees safety than it is to search thousands of programs for buffer overflows. I understand that every system will probably involve C, C++, or assembly at some level, but we should try to minimize the extent to which they are used in order to reduce the number of places where buffer overflows and other such problems can pop up. It wouldn't completely eliminate security problems, but if more programs were written in safer languages we could come close to eliminating the most common security problems.

  • Ability, luck, and language -- in that order (Score:5, Informative)

    by tmoertel ( 38456 ) on Saturday October 05, 2002 @10:39PM (#4395420) Homepage Journal
    Programming ability almost always dominates all other controllable factors, including choice of programming language, when it comes to most programming tasks.

    Simply put, programming languages are tools. Some tools make certain jobs easier than others, but tools only go so far. The rest is up to the programmer.

    In the case of this year's ICFP contest, Team Radical Too did well because they had a good strategy that ultimately fared well in judging. Their robot performs a semi-exhaustive simulation of the possible moves up to a certain degree and then chooses the best move based on the simulation results. (It's a cool approach, and the source code is worth a read.)

    It's a compute-intensive strategy, and my guess is that they selected selected C as their implementation language for this reason. They made the decision to sacrifice the high-level flexibility that other languages provide in order to have C's low-level control over how CPU cycles and memory are consumed.

    Oh, and then there's luck

    Despite how much we like to argue about programming ability and choice of programming language -- and competitions are perfect fuel for this particular fire -- we shouldn't read too much into the results of programming competitions. Luck plays as large role as any.

    I returned, and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.

    In the case of the 2002 ICFP Programming Contest, for example, I happen to know that several of the robots, including Team Radical Too's robot, will unwittingly commit suicide in situations where they have the opportunity to push another robot into lethal water that spans more than two board cells. In this situation, the attacking robot will push its victim into the water, killing it. The victim, although dead, appears on the game board the next turn (and is removed from the game on the turn after that). However, the attacking robot's logic fails to account for the fact that dead robots can remain on the game board for a turn before they are removed by the game server. It considers any robot on the game board to be alive -- including the now-dead victim, floating in its watery grave -- and hence fair game for attack. Seeing that there is water beyond the now-dead victim, the attacking bot will try to push it again, thus stepping into lethal water itself and effectively committing suicide. Oops.

    Luckily, the judges didn't have any wide spans of water in the map used for the final showdown.

    Indeed, chance happeneth to them all.

    • I think it would mean something if people with high programming ability always reliably selected certain languages to code in, and rejected others -- don't you? Maybe they pick certain languages because they are easier or better to program in.

      If they didn't, if instead they always picked the difficult language because they wanted to prove to the world that they were awesome enough to handle that language, then there is always the possibility that some dumb programmer with an ordinary language like C will come along and... wait a minute...

  • More lines in C, but same outcome. (Score:5, Interesting)

    by wackybrit ( 321117 ) on Saturday October 05, 2002 @10:41PM (#4395425) Homepage Journal
    It's all quite an easy debate really. Some people prefer higher level languages like Python, whereas some prefer lower level languages like C.

    What's the difference? The amount of lines you need to write to get the same result.

    It therefore goes that the more lines you need to write to get the same result, the more control you get over the program and the computer on which it is running. This means that programs in C can control the computer in better ways than programs written in Perl or Python.

    A lot of programmers, like C programmers, think that C, much like Ada, a language to program, in on problems such as objective and the logical ones. An interesting example is the difference between Visual Basic and Visual C++.

    In Visual C++, to open a window takes about 104 lines of code if you estimate the number without doing any research like myself. In Visual Basic, you can open a window just by creating a new project and hitting 'Run'. It's easy, and that's why it works.

    This is primarily true in the first instance, since there is proof that indicates such, although there is no evidence of this to suggest quasi-otherwise.

    • Lines it is! (Score:4, Insightful)

      by phorm ( 591458 ) on Saturday October 05, 2002 @11:29PM (#4395543) Journal
      That about clinches it. A lot of people really look down upon those who use any coding language that in any way simplifies the coding. The way I've always seen it is thus:

      Visual Basic is a very nice language for coding GUI-based applications. Newer versions have increased speed and performance such that there's not really a difference (exempting the included DLL's) between a standard office-type app made in VB and one in C++. If you want to get complicated and rip into the windows API, then you're probably doing something that may require C++, but VB often even handles this nicely. It interfaces much more nicely with the C-based DLL's than it used to in the past.

      My biggest peeve is the syntactical differences in compative operators and math. There was a time when I love VB, but now I truly hate having to do a "myvar = myvar+1", or the fact that you can't do something like "var1=var2+var3" (in VB that would give a boolean).

      In arguement for VC++, the wizards can handle a lot of the windowing/GUI stuff for you. I think that if if gave you some nice understandable error messages when you screwed up things might be a lot nicer. (it sucks when you get an ambiguous error message on line 2023 caused by a mistake on line 101).

      Since I've learned C++, I prefer it when possible. I have no huge qualms about writing a GUI in VB, or even a hybrid project with C++ DLL's linked to my VB GUI's. Every coder has their place. Just because one can program C and Fortran doesn't make them any better than a VB programmer. In a timed-trial for a small GUI app, the VB programmer would likely stomp the C progammer.

      If only MS could program better error messages... Error on line 342: unknown thingamabobber executing blingconfangler - phorm
      • Sure, VB makes it easier to pop open windows and stick buttons on them, but that has more to do with the flaws in the win32 API that people use when writing C++ aps for windows then any strength in VB. You can do the same thing in Visual C++, but filling out a few wizards, and clicking 'compile' you get your own window. Sure, VC generates a shitload of code for you, but you still don't have to.

        In contrast with languages like Scheme, Java, etc, which really do require less code to do anything visual basically actually impedes what you do, due to the seriously lacking language features. Classes can be done Via COM, but good luck if you want to do something like polymorphism, or passing functions around or whatever.

        I've coded in VB, and trust me, the reason people don't like it is because it's weak and it sucks. I constantly found myself smashing up against the limitations of the language. Things that would be easy to do in java or even C++ were impossible from a practical standpoint in VB.

        Of course, things may have changed some in VB.net. But considering the fact that VB.net isn't even compatible with pervious VBs, I couldn't really care.
    • In Visual C++, to open a window takes about 104 lines of code if you estimate the number without doing any research like myself. In Visual Basic, you can open a window just by creating a new project and hitting 'Run'. It's easy, and that's why it works.

      I remember getting into a debate with some kids about this in highschool. The next day, I'd produced a program that would bounce a ball around in a window in 30 lines of code.

      By "squishing" the code down (although, with only one semicolon per line, outside of for loops) I was able to get it down to 23 lines. Keep in mind I was in highschool.

      Anyway, if you want to see this for yourself, the source is up at http://autopr0n.com/23lines.cpp [autopr0n.com], and the complete VC5 (IIRC) is at http://autopr0n.com/23lines.zip [autopr0n.com]

      Oh, and looking over the comments, I still used windows messaging. If I wrote this code today, I'd probably be able to get it done with even less code.
    • What's the difference? The amount of lines you need to write to get the same result.

      I suppose Java is the highest-level language out there, since you can write your whole program on a single line.

      --
      Benjamin Coates
  • I started working on a solution but due to poor planning a test game server implementation was not available until late in the contest. I dropped out and said piss on it.

  • The limited scope of a contest tells you very little about either the proficiency of the programmer or the quality of the programming language.

    Only a task that's gonna take years and consume a few hundred thousand lines of code will really show which programmers can stand the pace over the long term, write *maintainable* code, document it well - and so on. Similarly, a program that's developed in a short period of time by a small team tells you nothing about how readable the programming language is. Some languages are easy to write in - but a bugger to understand a year later.

    Still, contests are fun - and that's enough to justify their existance.

  • Good programmers win (Score:3, Insightful)

    by gmarceau ( 119282 ) <dnys2v4dq1001@sneakemail.com> on Saturday October 05, 2002 @11:02PM (#4395480) Homepage
    Winning the contest is more about being a good programmer than about the particuliar programming languages.

    But then again, you can assume a good programmer would pick a good programming language.

  • What's this? (Score:5, Funny)

    by gmhowell ( 26755 ) <gmhowell@gmail.com> on Saturday October 05, 2002 @11:04PM (#4395484) Homepage Journal
    whose entry was written in C!

    I was just getting used to C#, now we are added C! ?

    How is that pronounced? 'see bang'?

    How is it different from plain C ?
  • I am seeing some post with the almost a Panic that their favorate language will die. I am still seeing Cobol and FORTRAN Codeing being used out there. So Dont worry your language will probably survive. I like to think languages are tools and I try to use the right tool for the right job. I find that I usually use Python the most for my work because I find it more efficient to use the List Class other then arrays, and my code is easier to maintain. But there are times where I switch to using C. When my code is needed to be optimised for speed. I program in JAVA when I need to be sure that my Code will run on other platforms. Ill make shell scripts when I need to do a lot of unix calls. I am sure that there are plenty of other languages out there that may do more tasks more efficiently then I am stating. But as a programmer you try to find the best tools that are available to you or that you have enough time to learn, to get the Job done. Just because someone one uped you by using another language dosent meen the language is out of date it just meen that the language my not be optimised for that particular job (Or your not as skilled programer as the other one in that area).
  • What language to use depends on many things -- including your experience and the way that you think about problems.

    C gives you lots of rope to hang yourself with
    OCAML, on the other hand lets you expressivly designate the contitions under which the rope will hang you.

  • Is Spanish better than English? Does Japanese trump Swahili?

    For any given language, the eloquence of the communicator far outweighs the syntax of the language. As with natural languages, it is harder to master the idioms of some languages than others, but that's all.
    • The fact that computer languages are somewhat metaphorically related to human languages does not mean you can use facts about human languages to prove things about computer languages.

      The only thing they even have in common is that they are called languages.
    • If you do speak multiple natuaral languages, you will realize that the language IS relevant.

      Especially some Asian language like Japanese that has ten ways of saying "me" depending upon the speaker's gender, age, and the context, is much different compared to English.

      To make the story short, language shapes the mind of its speaker.
      imho, gendered language like Hindi, Italian, Spanish... will always make its speakers see things in gendered manner. And Japanese language speaker will always see things in the respect level embedded in the language itself.
      And yes, C++ programmer will see problems in terms of object and its member functions, and polymorphism....etc.

      In Japan, there are probably twenty+ different ways of calling "rain," because it's a rainy country with four distinct seasons. In Mongol, there are whole bunch of ways of calling a horse, because of nomadic life.

      I am sure when you say "rain," in english, you are not going thru the thought process a Japanese will go thru when she hears "kirisame" or "tsuyu." And Mongolian nomads will see "horse" in a much different manner than you.

      • In Japan, there are probably twenty+ different ways of calling "rain,"
        April showers
        cloudburst
        deluge
        downfall
        downpour
        d renching rain
        driving rain
        drizzle
        flash flood
        freezing drizzle
        freezing rain
        heavy drizzle
        heavy rain
        heavy thunderstorm
        intermittent showers
        light drizzle
        light rain
        light shower
        moderate drizzle
        moderate rain
        occasional showers
        persistent rain
        rain
        rain belt
        rainstorm
        scattered showers
        sheet of rain
        shower
        sleet
        spate
        steady drizzle
        stream of rain
        thunderstorm
        thunder shower
        torrential downpour
        torrential rain

        That's just a few minutes of brainstorming, I'm sure there are more.

        -Kevin

        • What about me? (Score:2, Informative)

          by j3259 ( 614060 )
          "Rain" polly wasn't a good enuf example because it's hard to explain what I exactly mean by different ways of calling rain, but how about ten+ different "me"?

          I don't think English language will have equivalent translation for: watashi(formal), atashi(fem.), watakushi(formal), ore(rude m.), oi(dialect m.), boku(polite m.), sessha(polite obs.), jibun, unu(dialect), soregashi(obs.), chin(used by noble obs.), touhou(formal), onore(lit), wagahai(rude obs.)
          They all mean "me," but used in different context.
          Same applies to "you." like kimi, kisama, atana, omae, temee...

          The reason why there are so many ways of addressing one another is because Japanese human relationship is never even.
          And by using Japanese language, notion of respect level somehow slips in, and thus Japanese speaker will not have the concept of simple "you and I" even relationship. Because they lack the concept of simple "you and I," title names or names are more often used to address others instead of "you," "he," or "she" to clarify the respect level in the sentence.

      • To make the story short, language shapes the mind of its speaker.

        *yawn*

        You're ability to say things does not make them true. When will people learn this?

    • Is Spanish better than English? Does Japanese trump Swahili?

      What about Toki Pona [tokipona.org]? It's a small spoken language with 120 words [tokipona.org] that don't inflect. Whether Toki Pona is small in a practical way [scheme.com] or small in an impractical way [muppetlabs.com] is still up in the air.

  • as has been previously noted, the functional vs. non-functional distinction is only one of several, e.g., declarative vs. imperative, strongly-typed vs. weakly-typed, compiled vs. interpreted, etc.

    the promise of all newer programming languages is that they are easier to develop, understand, and maintain, because the programmer is elevated to thinking about the "big picture".

    i think it's possible to do great things in old languages like C. what it comes down to is, you need discipline. if the compiler/language design has discipline for you, great. otherwise, if you have alot of experience with alot of languages, and are anal, you'll do ok in a small group of similarly talented anal people. in a larger group or project, any not-automatically-enforced discipline will eventually be broken.

    unfortunately (?) i still do most of my programming in C/perl. that's because a) i need the solutions i'm developing to work 100%, and i can't afford to run into obscure under the hood problems in still-maturing technologies like ghc [google.com], and b) i like to leverage the huge body of existing libraries out there, and c) i have only worked on small projects (

    -- p
    • I think the point you are trying to make is that it is often better to be using the language most other people are using. The allows transfer/reuse of skills, tools, existing libs, etc.

      In a real world environment there is almost no reason to adopt a minority language - outside of everything else it often just creates a code-island. Now, if you can make OCAML the "majority" language of your group, you are set.

  • Does the skill of the programmer prevail over the limitations of the language and paradigm used

    Well, yeah. I mean, duh.

    Seriously though, while OCaml might have been a better language for the various problems, it should be possible to do it in C, assembly, PASCAL, whatever. It might not be a good idea but it can still be done.

    If the second team had known and used OCaml, or some other OO language... or hell even Java or C++ they would have had an easier time. But it may have been that they wanted to give themselves a challenge, to prove that they could do what some could do in OCaml in plain C.

    A while ago I was reading about how some proceduralist was complaining that these competitions weren't fair to non-functional coders. The argument made sense, but it shouldn't have been impossible to do the coding in a procedural language.

    In fact, I was thinking of doing the contest in Visual basic, just for spite :P
  • I don't understand how there can be an impartial "challenge task." Aren't some languages better suited to some tasks than others? I suppose if a language was truly superior the task would be irrelevant, but I don't believe such a superior language exists.

  • "Functional programming wins again" (Score:5, Funny)

    by ari_j ( 90255 ) on Sunday October 06, 2002 @03:39AM (#4396080)
    ...functional programming wins again...

    Of course it does, you idiot. ICFP stands for International Conference on Functional Programming

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close