Slashdot Mirror
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?"
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
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.
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.
-Kevin
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
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.
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.
I learned OCaml when I had pneumonia
:-)
That's about what it takes to put one in the frame of mind for it
Table-ized A.I.
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
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
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
ah, in this case, k is 0. You declared i, j, and k as integers. Division is defined on integer. In integer division, 1/2 = 0. Now, if you want a compiler that easily switches between integer and floats, thats one thing, but you probably shouldn't refer to them as "int" in that case.
no comment
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.
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.
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.
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.
The Oxford English Dictionary doesn't know what egantagious means. Care to enlighten us all?
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.
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.
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
No idea about pedagogicalness, but...
Personally, I started from LISP, and it has proven to be pretty useful. I use XEmacs, so writing stuff in elisp is kewl, and also many programs use Scheme as their scripting language, which of course made LISP skill valuable (Scheme is basically simplified LISP).
I don't know which really is better, OCaml or Haskell; I've personally only tried a little bit of Haskell - and I tried it because it was advertised as a purely functional language, something that made it a little bit more interesting.
But my day-to-day functional stuff is still all in LISP and Scheme =)
There's several possibilities
:) for a version that is not a strictly non-commercial trial version. That's why I ended up using O'Caml instead.
Haskell:
Nice language, but I've never found any implementation that is complete enough to use for real programs.
O'Caml:
Nice language. Nice implementation. Nice library. Currently what I'm using.
Scheme:
Very small lisp. Often used as an extension language (for example in Gimp). It's a common discussion if this is an academic toy language or if it's fit for real programming. I'm not quite sure. Anyway, it's easy to learn (the standard is only a few pages), and there's a nice book for it (The Little Schemer (don't let the cartoons and food receipies fool you, this is one scary book)).
Common Lisp:
Is paradigm adaptive. That is, if you want to write functional, you can. If you want to write imperative, that's nice too. It's my favourite language, but I've had problems finding an implementation that has ok thread support and costs more than a car (no pun intended
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
Functional programming eh?
I'd suggest the following three languages:
1. SML
SML is the language on which OCaml is based. OCaml is really just SML with different (read: worse) syntax, some small differences, and then OO support.
SML will probably be easier to start off on, is better supported and better documented.
Once you've got SML down, OCaml will be easy.
SML is strongly-typed, via type-inference.
2. Common Lisp
This is probably the most powerful language in existance.
Functional if you want. Side-effects if you want. Based on mathematical theory. Closure of data and code. With CLOS (builtin) you get an incredibly powerful OO system.
Common Lisp is dynamically typed and CLOS supports dynamic multiple-dispatch for typing.
Lisp's defmacro system will open your eyes to a whole new world. It is the most powerful macro system you'll ever use. You can perform arbitrary transformations to your code. You'll never think the same way again once you've gotten the hang of defmacro.
3. Haskell
A very simple language to pick up the basics of. Pure functional. Lazy evaluation.
A different idea than SML or Lisp.
I think those three languages would expose you to pretty much all of the concepts of functional programming as well as all the different kinds of syntax you are likely to run across in functional languages.
If you have some time to read up on lambda calculus it might be worth it.
I also strongly recomment both of Paul Graham's Lisp books.
Good luck,
Justin Dubs
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.
From the Caml Faq
The main reason is historical: Caml was invented before SML.
The Caml language is issued from the original ML language, invented by Robin Milner in 1978, and developped jointly at INRIA from 1981. The first Caml compiler was written in 1984, and distributed from 1985. Standard ML was not yet invented, and Caml's syntax was similar to the syntax of ML V6.2, whose compiler was used to compile the first Caml compiler. When the syntax of Standard ML has been defined, Caml kept its own syntax, for several reasons. The first reason is questionable and subjective: we thought that SML's syntax was not a major improvement of the original ML syntax (hence of Caml's one). The second, more fundamental, reason is that we thought the language not to be mature enough at that time to be completely defined and fixed by a standard; we are still doing some progress on the understanding of some features of ML, and these progress may imply some important modifications of the language (let's cite the type checking of imperative features or the semantics and type checking of modules). In addition, we wanted to be free to add some new constructs (and indeed we did it, e.g. ``for''loops, ``try with'' and ``match with'', character constants, access to vectors and strings, ``mutable'' annotations for records, ``when'' clauses in pattern matching). This relative freedom with respect to the syntax allows the emergence of new variants of Caml: for instance the Caml Light and Objective Caml systems have their own extensions to the core syntax of Caml.
Hence Caml has its own syntax.
More interestingly caml has a pre-processor(camlp4)which allows to write in various other syntaxes. E.g. there is a Standard ML syntax, as well as a lisp-ish syntax.
They both have nice documentation. They are so similiar I doubt it makes a lot of difference. The nicest new programmer ocaml documentation is The Oreilly Book Developing Applications with Objective Caml. With the exception of Ocaml's object oriented features, most ocaml documentation can be used w/ SML, and vise versa.
For whatever its worth, camlp4 gives you a nice macro system too. I don't know how it compares w/ common lisps, but it does give you static checking of your macros and let you work at the abstract syntax tree level.
I started with SML, but thought it was impractical. I think it was limitations with the library, but when you are generally frustrated, it's pretty hard to identify the exact cause. Anyway, it turned me off ML for a while. Until I discovered O'Caml. Really opened my eyes.
So my advice is to jump directly at O'Caml. SML might have a slightly more pedagogic or clean syntax, but an environment that makes you feel powerfull is more motivating and therefore more important in the start.
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.
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
Thank you for the corrections,
Justin Dubs
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?
I completely agree. 2x=1 cannot be solved without what you said.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
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.