Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community: in Pharo 3.0 one can write: Smalltalk os env or would it be better to use: Smalltalk operatingSystem environment in the future? So is the current Smalltalk vm better than Smalltalk virtualMachine I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations) Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms? Or will we keep abbreviations for the lazy and easier typing? If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann <astares@gmx.de> wrote:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
or would it be better to use:
Smalltalk operatingSystem environment
in the future?
So is the current
Smalltalk vm
better than
Smalltalk virtualMachine
I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible.
Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations)
Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms?
Or will we keep abbreviations for the lazy and easier typing?
If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
+1000 On Thu, Jul 4, 2013 at 12:57 PM, Max Leske <maxleske@gmail.com> wrote: > I agree wholeheartedly! I still believe in (mostly) self documenting code > and that cannot be achieved by using abbreviations. > > Max > > On 04.07.2013, at 12:52, Torsten Bergmann <astares@gmx.de> wrote: > > > Usually I thought only the C/C++ people fell in love with abbreviations > - but > > now its our own community: > > > > in Pharo 3.0 one can write: > > > > Smalltalk os env > > > > or would it be better to use: > > > > Smalltalk operatingSystem environment > > > > in the future? > > > > So is the current > > > > Smalltalk vm > > > > better than > > > > Smalltalk virtualMachine > > > > I know: even a newcomer should know what "OS" means. At least > Smalltalkers/Java people should > > know they need a "VM". But nonetheless I think a common goal would be to > keep > > Pharo code and method selectors readable and avoid abbreviations when > possible. > > > > Also there are Pharo methods like #getEnv: instead of > #getEnvironmentVariable: > > (interesting that they wrap the native C/C++ API > "GetEnvironmentVariableA" > > which does not use abbreviations) > > > > Should we care (with an issue) and use the more readable forms in > > the future and deprecated the abbreviation forms? > > > > Or will we keep abbreviations for the lazy and easier typing? > > > > If you comment please think about the goal to get readable code, the > goal to > > get more newcomers into programming and your own first steps with > Smalltalk > > and IT ... > > > > > > > > > > > > > -- Cheers,
+1 -----Messaggio originale----- Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Max Leske Inviato: giovedì 4 luglio 2013 12:58 A: Pharo Development List Oggetto: Re: [Pharo-dev] Abbreviations I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann <astares@gmx.de> wrote:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
or would it be better to use:
Smalltalk operatingSystem environment
in the future?
So is the current
Smalltalk vm
better than
Smalltalk virtualMachine
I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible.
Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations)
Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms?
Or will we keep abbreviations for the lazy and easier typing?
If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
or would it be better to use:
Smalltalk operatingSystem environment
in the future?
So is the current
Smalltalk vm
better than
Smalltalk virtualMachine
I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible.
Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations)
Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms?
Or will we keep abbreviations for the lazy and easier typing?
If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit ⦠zealous. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. Cheers, Henry
Am 04.07.2013 um 13:09 schrieb Henrik Johansen <henrik.s.johansen@veloxit.no>:
On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
or would it be better to use:
Smalltalk operatingSystem environment
in the future?
So is the current
Smalltalk vm
better than
Smalltalk virtualMachine
I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible.
Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations)
Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms?
Or will we keep abbreviations for the lazy and easier typing?
If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit ⦠zealous.
Simple abbreviations, like env, rather than using the full word, I have much less empathy for.
I like to avoid abbreviations as much as possible. But you are right when it comes to use very common ones I don't have a strong feeling about. To me I think vm and os are widely used so there is nothing to decipher in order to be able to understand it. The selector env I find not commonly used ( I know it mostly from console usage ). And there is Behavior>>#environment which I feel is inconsistent. Norbert
On 04.07.2013, at 13:09, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
or would it be better to use:
Smalltalk operatingSystem environment
in the future?
So is the current
Smalltalk vm
better than
Smalltalk virtualMachine
I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible.
Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations)
Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms?
Or will we keep abbreviations for the lazy and easier typing?
If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit ⦠zealous.
Agreed. There are conventional terms that can (and maybe should) be abbreviated. But in general I'm against abbreviations.
Simple abbreviations, like env, rather than using the full word, I have much less empathy for.
Cheers, Henry
+ One Norbert Am 04.07.2013 um 12:52 schrieb "Torsten Bergmann" <astares@gmx.de>:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
or would it be better to use:
Smalltalk operatingSystem environment
in the future?
So is the current
Smalltalk vm
better than
Smalltalk virtualMachine
I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should know they need a "VM". But nonetheless I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible.
Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" which does not use abbreviations)
Should we care (with an issue) and use the more readable forms in the future and deprecated the abbreviation forms?
Or will we keep abbreviations for the lazy and easier typing?
If you comment please think about the goal to get readable code, the goal to get more newcomers into programming and your own first steps with Smalltalk and IT ...
On 2013-07-04, at 12:52, Torsten Bergmann <astares@gmx.de> wrote:
Usually I thought only the C/C++ people fell in love with abbreviations - but now its our own community:
in Pharo 3.0 one can write:
Smalltalk os env
actually that #env there is more complicated than you think :) - `Smalltalk os` returns OSPlatform, the class - implementing #environment on the class side will break the compiler for this class My first attempt was of course to use #environment as a name, which failed horribly ;) So first we have to complete the refactoring that `Smalltalk os` returns an instance of OSPlatform. Only then we can move to #environment, which by looking at #OSEnvironment is the intended name. So all in all you detected the symptoms of a much worse problem, using class-sides instead of instances. In any case, I agree that #env is not nice at all...
participants (7)
-
Camillo Bruni -
Henrik Johansen -
Lorenzo Schiavina -
Max Leske -
Norbert Hartl -
Peter Hugosson-Miller -
Torsten Bergmann