Wow, this thread came alive from the archive!
Note that I wasn't advocating for or against brace notation.
But, if you are trying to write code that is portable across Smalltalk dialects, you avoid brace notation.
On my projects, I would rather maintain: dictionary := Dictionary new at: $a put: 1; at: $b put: 2; at: $c put: 3; yourself.
than { $a -> 1. $b -> 2. $c -> 3 } asDictionary
As I think it would be easier to update. I use literal forms to save myself typing but when I commit code, I'd rather have the long form. In fact, I've sent #sourceString to literal arrays so I could get the long form without all the typing.
On 5/14/08, Jason Johnson jason.johnson.081@gmail.com wrote:
On Wed, Mar 5, 2008 at 10:23 PM, David Mitchell david.mitchell@gmail.com wrote:
Brace notation for dynamic arrays!
So instead of:
dictionary := { $a -> 1. $b -> 2. $c -> 3 } asDictionary.
I need to type:
dictionary := Dictionary new add: $a -> 1; add: $b -> 2; add: $c -> 3; yourself.
? In my opinion the other dialects should adopt this or propose another way of doing it. No concise syntax for dynamically creating a collection seems a problem to me, and easy to remedy in a language where one has access to the reader/compiler. So why would it be bad to do so?
On Wed, May 14, 2008 at 6:41 PM, David Mitchell david.mitchell@gmail.com wrote:
Wow, this thread came alive from the archive!
Yea, sorry about that. I've been tied completely up for months.
Note that I wasn't advocating for or against brace notation.
Well, you aren't the first person to mention it, so I just thought the other side should be represented. I.e. I didn't mean it to be directed at you personally, but rather to defend dynamic array syntax.
But, if you are trying to write code that is portable across Smalltalk dialects, you avoid brace notation.
All dialects have a way to modify the parser don't they (probably a really simple way in many of them)? Maybe an alternative would be to just make a package that adds the syntax to any Smalltalk. Then people could use it if the want and just site the package as a dependancy.
As I think it would be easier to update. I use literal forms to save myself typing but when I commit code, I'd rather have the long form. In fact, I've sent #sourceString to literal arrays so I could get the long form without all the typing.
That is a good way of doing it, but the maintenance cost comes from how much code is there, not how much was typed. This is a huge problem Java has. Java wizards say "It doesn't matter how verbose the syntax is, I just generate all the boilerplate". But that doesn't help the guy maintaining the code very much.
On May 14, 2008, at 6:47 PM, Jason Johnson wrote:
All dialects have a way to modify the parser don't they (probably a really simple way in many of them)?
I don't think that Dolphin or GemStone/S have ways of modifying the parser.
... the maintenance cost comes from how much code is there, not how much was typed. This is a huge problem Java has. Java wizards say "It doesn't matter how verbose the syntax is, I just generate all the boilerplate". But that doesn't help the guy maintaining the code very much.
I thought that with Smalltalk we claim that the more verbose code was helpful for maintenance. I'd much rather have keyword selectors than comma-separated arguments. Also, I don't care much for syntactic shortcuts like dynamic constructors. Although people describe Lisp as simple, I keep getting lost on the meaning of a single forward quote, a single backward quote, a double quote, a comma, etc. One of the early languages I learned was M (aka, MUMPS), where the semicolon had four different meanings, depending on the context. Of course, we weren't conserving characters for the programmers or for the maintainers, but for the machine--each user had 2 KB for code and data.
James Foster
On Wed, May 14, 2008 at 8:12 PM, James Foster Smalltalk@jgfoster.net wrote:
On May 14, 2008, at 6:47 PM, Jason Johnson wrote:
I don't think that Dolphin or GemStone/S have ways of modifying the parser.
You misunderstand me. You have the parser code in your image and you can modify it. I meant that there is probably a "standard" way to do it in many of the Smalltalks. Though in Dolphin it isn't needed since they already have macros (the ## syntax).
I thought that with Smalltalk we claim that the more verbose code was helpful for maintenance. I'd much rather have keyword selectors than comma-separated arguments.
Well, you are applying the "verbose" label to something different then I am. Personally I prefer the keyword arguments and actually find it concise and self documenting. By verbose I meant "how many lines of code to do something" and "how much of this code is just silly boiler-plate that I just don't have a way to avoid".
I used to have a link of a study comparing Java, C++ and Smalltalk. At that time Java was 3 times more productive then C++ and Smalltalk 3 times more productive then Java, based on how much code the developer had to write.
Also, I don't care much for syntactic shortcuts like dynamic constructors. Although people describe Lisp as simple, I keep getting lost on the meaning of a single forward quote, a single backward quote, a double quote, a comma, etc. One of the early languages I learned was M (aka, MUMPS), where the semicolon had four different meanings, depending on the context. Of course, we weren't conserving characters for the programmers or for the maintainers, but for the machine--each user had 2 KB for code and data.
James Foster
But, if you are trying to write code that is portable across Smalltalk dialects, you avoid brace notation.
All dialects have a way to modify the parser don't they (probably a really simple way in many of them)? Maybe an alternative would be to just make a package that adds the syntax to any Smalltalk. Then people could use it if the want and just site the package as a dependancy.
I think modifying the parser is a pretty big expectation for an application or framework.
As I think it would be easier to update. I use literal forms to save myself typing but when I commit code, I'd rather have the long form. In fact, I've sent #sourceString to literal arrays so I could get the long form without all the typing.
That is a good way of doing it, but the maintenance cost comes from how much code is there, not how much was typed. This is a huge problem Java has. Java wizards say "It doesn't matter how verbose the syntax is, I just generate all the boilerplate". But that doesn't help the guy maintaining the code very much.
Wasn't my point. I think the long form is clearer. One of the great things about Smalltalk is the simple object+message syntax. Brace notation is something else. It can be handy at times, but I think the other form is clearer.
Wasn't my point. I think the long form is clearer. One of the great things about Smalltalk is the simple object+message syntax. Brace notation is something else. It can be handy at times, but I think the other form is clearer.
Yes, I agree, the first form is smaller, but to a causal observer, the second form makes more sense. I personally aim for readbility of my code, even by people that do not know the programming language, I would choose the second choice!
On Wed, May 14, 2008 at 5:07 PM, David Mitchell david.mitchell@gmail.com wrote:
But, if you are trying to write code that is portable across Smalltalk dialects, you avoid brace notation.
All dialects have a way to modify the parser don't they (probably a really simple way in many of them)? Maybe an alternative would be to just make a package that adds the syntax to any Smalltalk. Then people could use it if the want and just site the package as a dependancy.
I think modifying the parser is a pretty big expectation for an application or framework.
As I think it would be easier to update. I use literal forms to save myself typing but when I commit code, I'd rather have the long form. In fact, I've sent #sourceString to literal arrays so I could get the long form without all the typing.
That is a good way of doing it, but the maintenance cost comes from how much code is there, not how much was typed. This is a huge problem Java has. Java wizards say "It doesn't matter how verbose the syntax is, I just generate all the boilerplate". But that doesn't help the guy maintaining the code very much.
Wasn't my point. I think the long form is clearer. One of the great things about Smalltalk is the simple object+message syntax. Brace notation is something else. It can be handy at times, but I think the other form is clearer.
On Thu, May 15, 2008 at 12:07 AM, David Mitchell david.mitchell@gmail.com wrote:
I think modifying the parser is a pretty big expectation for an application or framework.
Depends on the point of view. It's the normal order of business in some other powerful language I know. :) But if doing something like this is alien to the Smalltalk culture then that is an important consideration.
Wasn't my point. I think the long form is clearer. One of the great things about Smalltalk is the simple object+message syntax. Brace notation is something else. It can be handy at times, but I think the other form is clearer.
Fair enough. I didn't mean to imply that you believe in the "Java way" or anything like that, but simply to point out the slippery slope that lies nearby. Code generation can certainly be very handy, one just has to avoid going overboard (of course I don't see your example as going overboard).
On 14-May-08, at 10:32 PM, Jason Johnson wrote:
On Thu, May 15, 2008 at 12:07 AM, David Mitchell david.mitchell@gmail.com wrote:
I think modifying the parser is a pretty big expectation for an application or framework.
Depends on the point of view. It's the normal order of business in some other powerful language I know. :) But if doing something like this is alien to the Smalltalk culture then that is an important consideration.
It's not *that* big a deal. Sure, it's not something you do every day, but there are quite a few projects in Squeak and other Smalltalks that use a custom parser or compiler.
Colin
squeak-dev@lists.squeakfoundation.org