> > Contrary to what most "modern" programmers would like to promote, I > > do not believe for one second that mandatorily garbage collected, > > bounded languages create better code design. > > I honestly can't see all this failing around of code written in > Python, Perl or Ruby :)
garbage collection is actually a compounding issue, meaning that while it may not be a problem for programs that are only active for a few minutes before terminating, it is a problem for programs that are high intensity or run indefinitely. it's typical (just ask an admin) for internally developed server side Java business database applications to require they be restarted daily because the devs cant figure out why they are "running out" of memory and it's easier just to have it restarted. if they were developing in perl, python or any other number of GC languages, it would still be an issue. while it /can/ be used properly, garbage collection is more of a hassle than it's worth. --Gravis On Mon, Mar 2, 2015 at 4:26 AM, KatolaZ <kato...@freaknet.org> wrote: > On Mon, Mar 02, 2015 at 02:59:40AM -0600, T.J. Duchene wrote: > > [cut] > >> >> Contrary to what most "modern" programmers would like to promote, I >> do not believe for one second that mandatorily garbage collected, >> bounded languages create better code design. I would subscribe to >> precisely the reverse, actually. If there is a flaw in the >> collector or the bound check, you have an extremely hard to fix >> problem that affects virtually everything. You are also >> continuously wasting resources on overhead for features that can >> fail without warning. Even if you set that aside, the reality is >> that you are investing in all of that wasted overhead for vanishing >> returns. At no time are those features a 100% effective solution to >> the problems they were intended to solve, and they create entirely >> new ones. So what good are they, really? >> >> Any code that does not work reliably isn't worth much. >> > > I honestly can't see all this failing around of code written in > Python, Perl or Ruby :) Bad code is bad code in C, C++, Perl, Python, > LISP, or whatever other language you can think of, and bad code will > either get better or die. IMHO the evil is not in any specific > language, but in the way you use it. > > Concerning "performance", well it is not always the most important > thing. I personally use C a lot for simulations and scientific > calculations, but I would never do data analysis and postprocessing in > C, since it would require every time a few days just to have a running > thing to be used only once or twice, while I can do the same task in > Python with 10 minutes coding and a few minutes more processing. In > that case, *my* time and *my* performance is more important than the > time it takes to the machine to crunch a few million numbers :) > > While I totally agree about the necessity to teach "good programming > practices" to young coders, I am convinced that there is no such thing > as the "perfect" language. It's just a matter of taste. And if you are > a good coder you will write good code in asm, C, Perl, Python or > Erlang. If you are not, then your code will be crap anyway :) > > HND > > KatolaZ > > -- > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
