4 ms·
I don't think that interpreted languages is the problem since people were using Visual Basic since the Windows 3.0 days. There are some collections in archive.o
by badsectoracula 9y ago
I don't think that interpreted languages is the problem since people were using Visual Basic since the Windows 3.0 days. There are some collections in archive.org for 16bit Windows shareware programs and games with hundreds of entries and like 2/3 of them are made in some version of VB.
Now, .NET and JVM might be a problem since those VMs tend to be resource hogs (after all both use GC methods that allocates tons of memory whereas something like Python or even classic VB use reference counting - even then there are languages that aren't using reference counting but some other method of GC and still are fast). But i don't think you should put all interpreted languages at the same box.
- pjmlp 9y agoReference counting is GC. Also you should not put all GC languages in the same box, as many do allow for AOT compilation to native code and do support value types and GC-free memory allocation as well.
- badsectoracula 9y agoHeh, it finally happened on Hacker News too, people misunderstood what i wrote and downvoted me for it instead of trying to understand what i am talking about (yes i am annoyed with that, it is one thing to be misunderstood and another to be penalised for being misunderstood - especially on HN where messages fade out when downvoted). So, first of all: > Reference counting is GC. How did you thought that i said otherwise when i clearly wrote "aren't using reference counting but some other method of GC" ("other method" here implying that reference counting is also GC)? Moving on... > Also you should not put all GC languages in the same box I did not, as should have been obvious from the "after all both use GC methods that allocates tons of memory whereas something like Python or even classic VB use reference counting" where i compare two different methods of GC, one that uses a lot of memory and another that doesn't. Now i get that making the previous misunderstanding would make this bit sound as if i was making a comparison between "GC" (Java, C#) and "non-GC" (Python, classic VB) - and please note that the quotes here are to show what one could think while having that misunderstanding, not what i really think, after all i already made it clear with the previous quote that i think that reference counting is a method for GC - however i do not think that it is my fault here, i gave examples and tried to make myself clear about what i mean. After some point i believe it is up to the reader to actually try and understand what i am talking about. I think the rest of your message (the "as many do allow for AOT compilation to native code and do support value types and GC-free memory allocation as well.") is relying on the above misunderstandings, especially considering i didn't do what you describe, so i am ignoring it. Now don't get me wrong, i am not attacking you or anything nor i believe you are wrong with the fact parts of your message ("reference counting is GC", "not all GC languages are the same"), it is just that the message doesn't have much to do with what i wrote.