3 ms·

In the last paragraph, the author talks about how (paraphrasing - the site won't reload, so I can't get an exact quote) Lisp provides a set of powerful tools th

In the last paragraph, the author talks about how (paraphrasing - the site won't reload, so I can't get an exact quote) Lisp provides a set of powerful tools that you can use to build any abstraction. I haven't really used Lisp beyond a few toy projects, but it seems, in this respect, to be similar to Javascript, which I do have quite a bit of experience with. The classic example in Javascript is inheritence. In his "Advanced Javascript" talks, Crockford lists three different patterns for inheritence, each of which is incompatible with the others. Furthermore, I know from experience that each of the techniques has some severe drawbacks - some (such as Crockford's "parasite inheritence") are incredibly wasteful of resources, keeping a copy of each function declared for the object with every instance. Others, such as "pseudoclassical inheritence" don't work if you want to inherit from a native object. I use Javascript for my day job, but my favourite language is Ruby. And I can't help missing the fact that it is much easier to share code with other people in Ruby (largely because it does have defined mechanisms for code reuse) than it is in Javascript. I'll never get two objects in Ruby that can't be used the same way because their system of construction is different. I appreciate that such flexibility helps with the expressiveness of the language, but when expressiveness comes with the price of not being able to easily work with others, I can't help wondering if the price is too high.

lukev 16y ago
This comes down to whether a languages is "opinionated" or not - whether it claims that a certain way of doing things is the best and makes it easy to do. I've realized I tend to like opinionated languages more. I still want it to be possible to do anything I want, but for the common case, having a sane, opinionated language lets me worry about my problem and not about, for example, implementing an object/dispatch system. Consider Clojure for a nice, opinionated Lisp.
kscaldef 16y ago
> I'll never get two objects in Ruby that can't be used the same way because their system of construction is different. Well, actually you might if they monkeypatch some core class in incompatible ways.
chc 16y ago
This depends on what you mean by "I'll never get two objects in Ruby that can't be used the same way because their system of construction is different." You have very few guarantees in Ruby, even fewer than in JavaScript. new_number = Fixnum.new # FUUUUUUUUUU- # Well, OK… new_number = Integer.new # OK, seriously? # Fine, then. Maybe some specialized classes are exceptions. this_should_work_right = BasicObject.new # Ah, it worked! puts this_should_work_right # WTMFH?!?!?!?! ClassA = Struct.new(:name, :age) ClassB = Class.new {attr_accesor :name, age} a = ClassA.new b = ClassB.new a[:name], a[:age] = 'Fred', 42 b[:name], b[:age] = 'Rick', 24 # Won't work
- bodhi 16y ago
  It took me a while to figure out how your comment was relevant to your parent, when I realised that you interpreted "system of construction" differently. (I humbly posit that) You are demonstrating how to create an instance of a Struct or Class, whereas the parent's intent was how the Struct or Class is implemented behind the curtain.

lukev 16y ago

This comes down to whether a languages is "opinionated" or not - whether it claims that a certain way of doing things is the best and makes it easy to do. I've realized I tend to like opinionated languages more. I still want it to be possible to do anything I want, but for the common case, having a sane, opinionated language lets me worry about my problem and not about, for example, implementing an object/dispatch system. Consider Clojure for a nice, opinionated Lisp.

kscaldef 16y ago

> I'll never get two objects in Ruby that can't be used the same way because their system of construction is different. Well, actually you might if they monkeypatch some core class in incompatible ways.

chc 16y ago

This depends on what you mean by "I'll never get two objects in Ruby that can't be used the same way because their system of construction is different." You have very few guarantees in Ruby, even fewer than in JavaScript. new_number = Fixnum.new # FUUUUUUUUUU- # Well, OK… new_number = Integer.new # OK, seriously? # Fine, then. Maybe some specialized classes are exceptions. this_should_work_right = BasicObject.new # Ah, it worked! puts this_should_work_right # WTMFH?!?!?!?! ClassA = Struct.new(:name, :age) ClassB = Class.new {attr_accesor :name, age} a = ClassA.new b = ClassB.new a[:name], a[:age] = 'Fred', 42 b[:name], b[:age] = 'Rick', 24 # Won't work

bodhi 16y ago
It took me a while to figure out how your comment was relevant to your parent, when I realised that you interpreted "system of construction" differently. (I humbly posit that) You are demonstrating how to create an instance of a Struct or Class, whereas the parent's intent was how the Struct or Class is implemented behind the curtain.