ICFP 2002 Contest Winners Announced
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?"
that's excellent news...good job ;-)
~ jon
The proficiency in writing programs means more. :
Most languages are functionally equivalent,
you can even have something like Alma
a program that translate a lot languages to a lot of other languages. It's fun to play with it!
I wasn't aware that C was no longer a good language...
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.
At the beginning was at.
I have no clue what the hell any of this is about.
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
My entry is listed as well. The order of listing is just when people submitted links to writeups, not the winning order.
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
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.
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.
If you can't see this, click here to enable sigs.
Does anyone else find it funny that this thread about whether or not language matters is rife with spelling and grammar errors?
(And yeah, I'm sure that I have made a few erros as well)
I don't think it's reasonable to say that either one of C or O'CaML is better than the other! They're so different that it would be like saying "wood's better than steel"!
Obviously it depends on the purpose...
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 do you mean by "finally"? Is there some compelling reason those stupid fucks should get press here?
-Kevin
http://www.kuro5hin.org/story/2002/10/5/01620/5630
Meh.
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.
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.
Easy, automatic testing for Perl.
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.
mogorific carpentry experiments
There's a reason why the Linux kernel is written in C. Because C is faster and more egantagious than languages like Python. You couldn't write the Linux kernel in a language other than C, it just wouldn't work and would lack power if it didn't.
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.
Got Code?
- All of the robots were subjected to a battery of solo games and games against reference robots provided by the judges
- The twenty highest-scoring robots went to the second round and played a number of games against each other.
- The eight highest-scoring robots went to the third round and were subjected to further games.
- Finally, the top two robots battled on symmetrical maps with each being allowed to start from the various starting points an equal number of times (to rule out starting-point bias).
The judges indicated that they would be posting more information later. The conference is still going on (in fact, ICFP is part of PLI, which is going on through 8 Oct), so give the guys a chance to get home and write something up. You'll get the details in due time.Easy, automatic testing for Perl.
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.
www.sjbaker.org
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.
This post was compiled with `% gec -O`. email me if you need the sources
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 ?
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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).
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Funny that the second place went to Tom Rockicki of dvips and AmigaTeX fame.
I remember that some of his Amiga hacks were uberkool. A realy cool hack of his was a superfast "game of life" cellular automaton implemented on the Amiga's "blitter" coprocessor. Very cool.
-- Anonycous Moward
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.
Free Software: Like love, it grows best when given away.
If the language was "C!", you'd see an extra period: "whose entry was written in C!."
But don't take my word for it:
- Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) 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 (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: 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 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.Easy, automatic testing for Perl.
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.
Karma Clown
int i = 1, j = 2, k;
k = i/j;
k does not equal 0, OK? One over two is the fraction 1/2, and not 0. If you're writing code like this, you are an idiot. Only idiots are contrained by the machine. Geniuses think like people and use languages that understand enough of math to arrange their types (strictly or no) in a tower instead of as disjoint sets of static rules that make it easier to write compilers instead of software. I do not care how hard it is for open source geeks to write compilers anymore than a user cares how hard it was to write a browser in C.
Programmers use compilers, and compilers should allow programmers to think abstractly instead of like a machine.
1/2 = 1/2, not 0. GET IT FUCKING STRAIGHT, YOU MORONS.
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
C++ is a joke. If your problem does not allow you to use memory opaquely--that is, if you must exercise control over the way code and data is laid out in physical memory--then you should use C. That accounts for 1% of all code written.
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'...
"Karma can only be portioned out by the cosmos." -Homer Simpson
THAT'S THE WHOLE POINT, YOU IDIOT. IT'S THE DIFFERENCE BETWEEN THINKING ABSTRACTLY AND AND IN ASSEMBLER. CPUS THINK IN ASSEMBLER. THAT'S WHY WE NEED COMPILERS.
You should not draw too many conclusions from the language that was used for the winning entries.
Oh, sorry, I forgot where I was.
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.
You know, it's not very nice to use foul language and call people morons when it is you yourself who have made the mistake. See other replies.
Regards
James
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.
first of all, for a programming task as small as this one, leaking is not a concern. it isn't something you'll ship to millions of people and have running all the time. if you are in fear of leaking megs of memory in a few days' worth of code and a few minutes of run time, then you have other problems.
second, if i want to free memory, ill free it. if im dumb and forget to free memory a lot, ill use smart types that are freed when they fall out of scope. why would i want to have something freed at some unknown time AFTER it falls out of scope?
If I recall a buffer overflow causing a security compromise typically depends on overwriting a stack pointer (stored on the stack "after" the space that we want to be written to).
So what I find myself really curious about is just how does garbage collection come into it?
- chad
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.
Proud member of the Weirdo-American community.
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, and b) i like to leverage the huge body of existing libraries out there, and c) i have only worked on small projects (
-- p
Does the skill of the programmer prevail over the limitations of the language and paradigm used
:P
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
autopr0n is like, down and stuff.
In fact, Lisp is the orgional functional programming langauge.
autopr0n is like, down and stuff.
Timothy wrote:
Well, duh. Skill counts more then language in everything. If the average slashdot-reading-geek got into a debate about anything with, say, Bill Clinton, who would you bet on? Conversely, if that same slashdot-reading-geek got into a debate with dubya, I ceertainly wouldn't be betting against the geek.
To put it another way, pick a programming language you know, and look at what you wrote when you first learned the language vs. what you write today. The language hasn't changed, it's your skill in it.
Karma: Food Fight (Mostly affected by Date Plate).
Autopr0n wrote:
A really good psychotherapist might be able to help you with your masochist tendencies.
I mean, I'm all for allowing people to stick nails through their hands for religious reasons, and whatever consenting adults in the bedroom is between them, but I've gotta draw the line somewhere.
Oh, and you have a ladybug climbing down your screen.
:]
Karma: Food Fight (Mostly affected by Date Plate).
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.
autopr0n is like, down and stuff.
What I was hinting at is that using other languages does not magically make your programs reliable or secure, though obviously it helps. There's more to it than removing pointers. No language is intelligent enough to realize what a programmer's intentions are and then carry them out with optimal efficiency. Even specification languages like NASA uses have many limitations. For starters, they run on hardware that is not 100% perfect, the bane of proving software correctness.
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, and the complete VC5 (IIRC) is at http://autopr0n.com/23lines.zip
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.
autopr0n is like, down and stuff.
Performance, timing constraints, general efficiency... When you write data to disk it is not immediately physically written out (unless you are using unbuffered I/O on a direct I/O filesystem without hardware caching). In both cases the action is performed logically but not physically in order to increase performance.
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.
autopr0n is like, down and stuff.
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.
autopr0n is like, down and stuff.
Good luck getting it to produce a binary for Red Hat 7.3.
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.
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.
My only political goal is to see to it that no political party achieves its goals.
Can anybody who is familiar with some of the functional languages recommend for someone with a few years experience with Java, Python, and XSL (yes, it is a Turing complete declarative language)? Basically, I would just like to play around with some functional language. I'm thinking about OCaml and Haskell. Any thoughts about which is better for pedagogical purposes?
I believe the implications are (and this stretching a little to make sense of the original post) that, with proper GC and proper abstraction, the following would happen:
FWIW, this happens to be how perl behaves with 'my' variables.
--JoeProgram Intellivision!
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.
FoundNews.com - get paid to blog.,
...functional programming wins again...
Of course it does, you idiot. ICFP stands for International Conference on Functional Programming
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.
// only the code never lies.
Nice try, but your interpretation of the division operator is wrong. Other posters have already pointed out the mistyped data, but I'd just like to say / ON INTEGERS RETURNS THE QUOTIENT, quotient being result of division without the remainder. So, yes, 1/2 = 0(quotient) + 1/2(remainder), but you only asked for the quotient, not the remainder.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Haha. And one day, bold people will even implement this VM on a true microprocessor! Imagine that! Sorry, but this was created long ago, with the whole family of Lisp machines (yes no C, only Lisp used as a system language), see one of the last attempt
No, sorry, ocaml is written in ocaml. Sure there is a minimal ocaml written in C that is used for bootstraping, but once the first ocaml compiler is compiled from C code, it is used to build the real ocaml compiler.
Sven Luther
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.
Karma Clown
There is very little more to it than removing pointers, since a good 90%+ of exploits are buffer overflows. It will magically make your program more secure by doing so. Now all you have to do is not do something stupid like open files you shouldn't, and that should take care of the rest :).
Karma Clown
Why do you assume garbage collectors are written by complete morons? If you are using a decent language, 100% of the memory is reclaimed after a full garbage collecting cycle. Maybe it will be once every hour, or once every second, but guess what, it is extremely carefully tuned by the garbage collection programmers. Paranoid people, and people with a good reason, can still force a full garbage collection when they want, reclaiming 100% of the garbage. What's your point?
second, if i want to free memory, ill free it. if im dumb and forget to free memory a lot, ill use smart types that are freed when they fall out of scope. why would i want to have something freed at some unknown time AFTER it falls out of scope?
Because you don't care, and it's damn expensive to do manually what a computer could do automatically - if you make only *one* mistake your program will leak or crash. Are you manually cleaning up '/tmp' 15 minutes, for fear that a program might have left something there AFTER the file fall out of scope?
...Perl converted to C? (there is a cmd line option in perl to do this... I have forgotten what it is)...
The only way to translate Perl to C is to create a copy of the Perl interpreter (runtime system) and the Perl compiler, in C, which is what the Perl compiler option that you're thinking of does. The Perl compiler saves you your initial parse and compile stage and that's about it. It does not compile Perl in any ordinary sense of the word. Perl cannot be translated into C, because of its support for such features as runtime execution of dynamically created program text. Other highly dynamic features such as closures would be equally impossible to translate into C without a complete Perl interpreter.
So, two parents divorce, and each gets half.
Problem is, they've only got one kid.
How much does each parent get?
The story of Solomon points out that there are indeed discrete, indivisible quantities in this world that humans deal with on a regular basis. Though physically, the "type conversion" of the child into two bloody halves is possible, it's not likely what any programmer or parent wants.
All sorts of other discretes exist for programmers. How many packets can I send, given one hour? 4/10th's of a packet is not a packet sent. How many widgets can be produced? A widget almost produced can't be sold. And so on. There is reality other than floats, good sir.
--Dan
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.
// only the code never lies.
Good point, thats true. I have a coworker who also brings up lisp machines as a counterexample. JXTA chips (which I think are Java-on-silicon) haven't been a roarding success either...
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.
He just told you C sucks because it forces you to think at the level of the CPU instead of people or math, and here you are telling him to think like a CPU. The point is, C's type system is unsuitable for program development. What--you think you're smart because you understand the semantics of C types? You have to be smart to see why they're stupid, stupid. Any dork can understand C.
but I do tend to agree that the best way to program in Brainfuck is to write a Something -> Brainfuck converter.
Right. That's why we have compilers. Brainfuck is assembly language for Turing machines, with CBF being the bytecode.
Will I retire or break 10K?
If your problem does not allow you to use memory opaquely--that is, if you must exercise control over the way code and data is laid out in physical memory--then you should use C. That accounts for 1% of all code written.
That may account for 1% of the code written, but it may count for a vast majority of the cycles run on computers. Most computers are not workstations or servers; they're embedded systems in refrigerators, microwaves, toasters, telephones, and game consoles. For those restricted environments, you really do need a low-level language such as C.
Will I retire or break 10K?
This case isn't entierly language agnostic, implementing "complicated" algorithms is easier in a higher level language than in a lower level one, memory allocation can get quite hairy. But frankly, few ICFP tasks have been more language agnostic. There're simply so many completly different strategies to chose from for this problem that chosing the right one is the only thing that matters. Radical Too did one very smart thing, they knew the advantage of their language was execution speed and they went for an algorithm which uses this advantage to it's maximum, an semi exhaustive search algorithm. Instead of chosing to implement a "smarter" (in the AI sense, not in the programmer sense, their algorithm is plenty clever) and harder (more abstract) algorithm in which their language couldn't shine.
Someone else did chose even more wisely, however. Such is life and the imperative languages have still yet to see a victory in ICFP. It's comming though, especially with more contests like this one.
-
Listen. Strange women lying in ponds distributing swords is no basis for a system of government.
I thought genius' were also supposed to be able to spell, but then someone like you probably doesn't concern "contraining" himself to the English language.
--"You are your own God"--
but the first version of Lisp (way back in the '60s, I think) was a pure functional language.
LISP was originally meant to be a Fortran replacement. Heck, its original syntax specification (M-expressions) was designed to look like Fortran; the parentheses you see on modern LISP are from the S-expressions that the first interpreter used internally. Are you sure that the first popular LISP interpreter didn't have what would become Scheme's set! instruction?
Will I retire or break 10K?
It would probably be prohibitively complicated to create a new, privilege-separated user for each robot-controller instance. Therefore, my entry would:
:>).
1) Contain a very, very (VERY!) basic algorithm for pick and drop of packages, sufficient to ensure only that my robot isn't killed and scores at least one point.
2) Hijack socket connections from other robot-controllers and send arbitrary malformed commands ("j00 h4v3 b33n h4x0r3d" would be an option, of course
I see nowhere in the rules where this would not be allowed.
And, of course, this would all be programmed in either TECO or, preferably, bash and netcat.
Mwahaha!,
Dan
SQL is not a turing-complete language
Neither is any other programming language in existence on a real machine. A Turing machine has an infinitely long memory. Real computers are called "linear bounded automata" (LBAs), which means a Turing machine with the modification that the memory is limited to a constant multiple of the size of the input, and trying to go off one end of the memory makes the head hit a brick wall. It's even possible to solve the halting problem on LBAs: just emulate two copies, one at double speed (tortoise/hare setup), and stop when the state and memory of both machines become identical, which means that the faster LBA has looped.
PL/SQL and its free clone PL/pgSQL are imperative languages that are just as LBA-complete as C or Scheme.
Will I retire or break 10K?
I've worked out a surprisingly functional socket class system in VB. I'm working to make a similar one in VC++ to replace it (instead of using hacky VB code to get back certain functionality issues). After that I was hoping to code something for my linux machine so that I can make apps that do basically what you just described: communicate with the linux machine from the windows machine through custom socket interfaces.
What do you use as a reference for this? I haven't coded any C-type stuff for linux (just Perl scripts) yet but I would be most interested in getting started. I so any good reference-material would be good, particularly in reference to sockets. I suppose I could also code something like this in Perl as well?
I've been told that sockets on linux behave in a similar way to those in windows, so perhaps it won't be too large a gap to bridge in my case, just need some samples to get me started.
There are 11 types of people. Those who understand binary, those who do, and those laugh at those who do - phorm
I'm a software developer and a chip designer, hense the two pairings of languages I mention.
One thing I have noticed is that some languages of the same genre take a heck of a lot more typing to achieve the same thing than others. For instance, the source code to a chip designed in VHDL would probably take on the order of twice as much space as one written in Verilog (we'll assume they result in identical logic).
So we should use Verilog then, right? Not necessarily. VHDL is a more strict language, more strongly typed, etc. You have to do all that extra tying because you have to specify things that the synthesizer uses to check to make sure you mean what you say you mean. The result is that Verilog may require more debugging time. The VHDL synthesizer will catch far more of your errors at compile time than the Verilog synthesizer. Would you rather spend hours going over compiler warnings or days doing gate-level simulation because your design doesn't work?
This is why Ada, as annoying as it is, is a safer language than C. C takes less up-front work, but while Ada helps you explicitly to write a bullet-proof program, it's FAR more difficult to do that in C.
Scripting languages are another issue entirely, and I'm no expert on them. But they fall into a different class from these.
The real purpose behind this contest is to show that functional languages are good ways to do things. However, this goal shapes the competition in such a way as to offer strong advantages to functional languages.
Specifically, as will be evident from the competition task description, it does not require the programmers to do the things that are really difficult in programming. Specifically, building good quality user interfaces, accessing and controlling devices, and working in an environment where the specification changes all too frequently.
The competition would have been more realistic if it required the programmers to provide a good quality user interface for the game, including communicating with its competition over an IP network, and, half way through the contest, changing the specification to require that a human user can take over the game at any point.
Now that would be a good competition, however, functional languages would fall on their face, and that would defeat the basic goal of this contest.
If you are using a decent language, 100% of the memory is reclaimed after a full garbage collecting cycle. Maybe it will be once every hour, or once every second, but guess what, it is extremely carefully tuned by the garbage collection programmers.
Would you recommend using a garbage collector in a real-time application such as a video game? I suggested it once on a video game programmers' mailing list, and I was told that anybody who would use one should be shot.
Will I retire or break 10K?
Is Spanish better than English? Does Japanese trump Swahili?
What about Toki Pona? It's a small spoken language with 120 words that don't inflect. Whether Toki Pona is small in a practical way or small in an impractical way is still up in the air.
Will I retire or break 10K?
Go HURD!!! (well, at least theoretically...)
Speed is not rated nearly high enough as a factor in the competition. One second per move is ridiculous. The C entrants rarely used more than 0.01 seconds per move, while the O'Caml and Python entries used 50X more CPU on average. The 'superior' O'Caml solution would not fly in the real world due to their slowness.
I bet the O'Caml winner would have taken _days_ to complete a large board. I would certainly hate to be the judge in such a competition.
Having said that, I do like their contest despite not being a fan of their judging criteria.
I forgot about the lack of threading. That one's just absolute murder.
autopr0n is like, down and stuff.
Don't those usualy involve something being, you know, funny?
Or was I mistaken?
autopr0n is like, down and stuff.
You missed "deluge" "showers" and "storm"
autopr0n is like, down and stuff.
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?
autopr0n is like, down and stuff.
Because making that memory immediately reusable requires more recordkeeping. Copying collectors don't have to do work for each and every dead object--they can relocate the live objects and then make the entire region reusable in constant time.
OO languages were not designed to deal with design problems that occur in projects gestated in 72 hours.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
*yawn*
Did your ability to post "You're ability to say things does not make them true" make the statement true? When will you wake up from the never ending loop?
Altho it is interesting, that there is Japanese superstition, kotodama(sprit of words), that they believe whatever they say will have spirit and will come true... but I don't buy that crap.
And don't tell me you believe in "truth." It becomes a disgusting religious war if you start mentioning "truth." There is no absolute truth. Go back 1000 years, Sun goes up and down would be "true," and it does from observer's point of view.
Then what am I saying here? Think.
It's not the "truth" I'm talking about, I am simply sharing a story I *know* from my own experience. And sharing of knowledge will only make sense if you do it rationally with supporting arguments and evidence to back you up.
You can agree if you wanna, and you can of course diagree, too. I am not claiming it's the truth. I am simply testing if you can see what I see. (@see paradigm)
If you do speak several natural language, or if you can think in some object-oriented programming language, you will realize that the speaker has to adopt herself into the notions of the language she is trying to speak.
Imagine C++ programmer who doesn't understand the notion of type. She will complain int k = 1 / 2; is not "0.5"
So it's a loop, the culture shapes the language, and the language shapes the speakers, and the speakers form the culture. Get it?
So, my point is that the language did matter after all.. Take some vacation, learn new language and travel outside your country. You will rediscover yourself.
# Sorry my English sucks. but you get the story..
// only the code never lies.
and working in an environment where the specification changes all too frequently
you obviously never entered this functional programming contest before - the spec changes by the hour!
> I mean, what happened? Which teams did what? Was anything interesting learned from this? Give us an overall ranking of all entries.
The detailed results are now posted.
I have a problem with the judges' scoring methodology. They simply totalled points across all the trials. However, different maps had different maximum amounts of points available, so that the results on a few maps dominated the results on the rest of the maps.
It would have been more fair to use, say, percentages of the maximum score acheived on a particular map, so that the maps were weighted equally.
Ian
First thanx to WetCat.
... In fact the syntax of lisp is () and that's all. My opinion is you can not parse lisp without executing it.
;-) Alma is already usefull but full of bugs. Alma will evolve and Ocaml will be parsed.
I have a few remarks on what was written here. The current release of Alma is based on a common OO model. For this reason, Alma is actually focused on OO languages. Some procedural languages (Fortran, C) can be parsed but procedures and functions are viewed as static methods of the Global class.
I had programmed for more than 6 years in Lisp (at work). I like it but you can not make big projects with it. My Lisp project was around 120K lines (and a lot more generated) but was quite impossible to maintain. For big projects, you *need* types and static check.
Functionnal languages are nice and powerfull but they have strong limitations for big projects (even with OO extensions). You should learn them but I'm not sure you should use them (for big projects).
Will Alma parse them ? The main problem is that functionnal language are mainly interpreters. Most of the keywords are in fact functions (and there is more than 2000 standard ones) which can be redefined, renamed,
The model of Alma could be extended to functionnal features but I think you couldn't write a parser. Anyway a parser will be written but it will parse only a few standard functions and nothing else.
Finally, Alma can generate some Lisp code. This code is not perfect. It uses CLOS (common lisp object system) but it can already save you a lot of time.
About SQL, you have to distinguish SQL2 and SQL3 (or equiv). SQL2 is not a programming language so Alma only generates SQL instructions to create tables. SQL3 tends to be a kind of programming language so you could translate a lot more.
Alma is "Translate 95%". Alma is a lot more. It adds Design by Contract to all languages, it adds Litterate Programming, it adds Design Pattern. And it can generate some UML diagrams. And...
And Alma is not finished
Regards, Guillaume Desnoix
You also have to write no lines of code in Borland CBuilder/Kylix. Why are you using Visual C++?
thank God the internet isn't a human right.
Hmmm, why not search on freshmeat for one of the many libraries that alow symbolic maths.
// 3*n // 18
As a simple example
sym n;
function = 2*n + n;
cout function;
n =6;
cout function.eval;
thank God the internet isn't a human right.