On Thu, 2013-08-29 at 09:08 +0200, Ralf Mardorf wrote: > On Thu, 2013-08-29 at 07:06 +0200, Ralf Mardorf wrote: > > On Thu, 29 Aug 2013 02:02:11 +0200, <berenger.mo...@neutralite.org> wrote: > > > > > > > > > > > Le 29.08.2013 01:13, Cousin Stanley a écrit : > > >> Ralf Mardorf wrote: > > >> > > >>> .... > > >>> Assembler always is optimized code. > > >> > > >> Not always .... :-) > > >> > > >> One can also write stinky code in assembler. > > >> > > >> Like any programming language, > > >> some programmers are better at it > > >> than others .... > > >> > > >> > > >> -- > > >> Stanley C. Kitching > > >> Human Being > > >> Phoenix, Arizona > > > > > > This is something I understood very recently, and the reason for which I > > > stopped to aggressively disdain Java and C#. The problem is not the > > > language, it's the language's user. Always. If eclipse is slow, huge and > > > buggy (in my experience, 2 years ago, it was.), it's not because it's > > > written in Java, there are very good programs written in Java, and in > > > Debian, you can find games with graphics of 90s, written in C or C++, > > > which are slow as hell on a modern computer. > > > > > > And nowadays compilers can make code better optimized than you could, > > > too. The question is, what is real optimization? Speed? Size? How many > > > of one? Or of both? > > > > > > Before that, I learn that it was not windows itself which was buggy, but > > > the softwares I was using. I discovered that last one when I discovered > > > linux, and had some crashes ;) > > > Sounds like it's easy to say it's the language/OS 's fault, and never > > > the programmer's one. Probably easy, but so often wrong. > > > > > > I think time made me wiser on those points. (funny to notice that when I > > > was a windows users, I was used to write "window$" and "M$" and other > > > insulting transformations which are far worse. Stopped that by > > > discovering another OS.) > > > > I guess a high level language like C, Pascal, Basic etc. is harder to > > learn than Assembler, while there for sure are reasons that you nowadays > > program in C. Optimal optimization are speed, size, functionality and > > stability. Sure, first steps can be easier done with high level languages, > > but the result usually will be spaghetti code. > > > > Clear formatted, easy to understand, but insane: > > > > Output_to_screen_command "Hel" > > jump_to label_x > > label_y > > Output_to_screen_command "world" > > jump_to_label_z > > label_x > > Output_to_screen_command "lo " > > jump_to label_y > > label_z > > finish_program_command > > > > So you learned how to make your computer say "Hello world" and how to jump > > in R.A.L.F., but you did not learn when it's useful and when it's insane > > to use the jump command in R.A.L.F. ;). > > PS: > > A coder can be aware that for a multiplication e.g. only integer > multiples of 2 without overflow could happen, so the code for the > multiplication only will be rolling bits and not including a rout, that > is able to do any kind of multiplication. If a coder would use a high > level language and use "x * y" the code isn't optimized anymore, but > instead it's unneeded bloated.
PPS: Even for x * 2, x * (2 * 2) etc., while x is defined as integer, since a compile couldn't be aware, if there is or isn't the need to take care for overflows. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1377763440.684.26.camel@archlinux