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. -- 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/1377760121.684.7.camel@archlinux
