> It's hard to understand why Ruby would allow semicolons to be optional bu=
t not "end" keywords.=0A=0AThere's necessarily a newline where the semicolo=
n would be no? This makes the ommission of semicolons more of an obvious ch=
oice to me than removing ends.=0A=0A> My best guess (and personal reason to=
 be against such an option) is that it would add complexity=0A> to programm=
ing and maintaining Ruby code without actually providing new functionality =
(it would only=0A> add a new syntax option).=0A=0A+1: you don't want to mir=
e the progress of a language by constantly seeking backward compatibility, =
but at the same time it seems like a _lot_ of upheaval for a small change.=
=0A=0A> Any time any language change is proposed, one could use the same ar=
gument: there is <language_that_contains_feature_x>=0A> for those who want =
feature x.=A0 I want the Ruby language, but I think it might well be improv=
ed by making a change.=0A=0A+1: new to Ruby and the list, so hope I'm not t=
oo rude in saying I'm not impressed with some of the attitudes of 'piss off=
 and use a different language'. Everything's discussable!=0A=0A> There is s=
imply no perfect programming language. If one would exist it would be the o=
nly programming language=0A> and we would all be using it.=0A=0AIMHO if tha=
t logic was right, then you're effectively saying all software studios are =
using the best tools for the job?! Popularity isn't the gauge of utility. =
=0A=0A> Maybe any code in any language should be stored in some generic for=
m meta language (we would have enough space to=0A> store it now - car crysi=
s left enough oil to create magnetic tapes) and the _Editor_ provides the v=
iew which best fits to the=0A> current developer. (Example: translate keywo=
rd to japanese signs, direction of writing a.s.o.)=0A=0ALove it! Be interes=
ted to see anyone playing with that idea in any language. It'd certainly so=
lve the endless debate.=0A=0AA.