Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If-statements in Smalltalk (2008)

pozorvlak.livejournal.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: If-statements in Smalltalk (2008)

#31

Post by TeMPOraL »

correnos wrote: post #19
plafl wrote: post #14

Earlier quoted context omitted.

I was drawn to python because of the culture (simple, documentation) and I stay because of the libraries (machine learning, scientific). The language just needs to be better than Matlab or R (not Scheme, Clojure, Scala or pick your favorite one). As in nature the language that thrives is the fittest for its environment, not the most powerful.

> As in nature the language that thrives is the fittest for its environment, not the most powerful. Now hold on. The most successful sprog of nature is humanity[citation needed] and we're a case study in the fact that raw intelligence is more effective than fitness for any particular niche. So: as in nature, there may be a bunch of niche languages, but in time they'll find themselves with a conservation status while…

So tell me, how is it that Python and JavaScript now seem to rule the Earth, instead of being locked up in a nature reserve?

Re: If-statements in Smalltalk (2008)

#32

Post by TeMPOraL »

plafl wrote: post #14
noobermin wrote: post #6

First, I did not know this, it's pretty cool. But, for all the fangled cool things that the more powerful languages of yesteryears (like lisp), what seems to actually precipitate adoption is simply history, not necessarily expressiveness/powerful abstractions, etc. See C, sh and friends, javascript. Arguably, python is one where its ease made it popular and it continues to develop language wise, albeit not without co…

I was drawn to python because of the culture (simple, documentation) and I stay because of the libraries (machine learning, scientific). The language just needs to be better than Matlab or R (not Scheme, Clojure, Scala or pick your favorite one). As in nature the language that thrives is the fittest for its environment, not the most powerful.

> As in nature the language that thrives is the fittest for its environment, not the most powerful.

Now, this is an important observation, but it needs one caveat - "fittest for its environment" != "fittest for the stated purpose". I.e. an objectively better tool may lose to a tool that's barely good enough, but e.g. provides a better CYA for managers, in a self-reinforcing loop of popularity.

That's the essence of Worse is Better - shit that's barely good enough will outcompete proper solutions.

(For many, that essay seems to be an ideal to follow; for me personally, it's just the description of the sad state of reality that we need to learn to work around.)

Re: If-statements in Smalltalk (2008)

#33

Post by aaron-lebo »

pg314 wrote: post #20

Since if-statements are built out of blocks and message sending, you can easily do some cool things. One of them is building up an abstract syntax tree (AST) of an expression without parsing that expression. E.g. suppose you want to build up an AST of the statement (x Instead of starting with an x of type Number, you would start with an object of type ASTVariable, that responds to the message As an sexp: (ASTIfStatem…

Is this a bit like a runtime macro? Does it have performance disadvantages?

Re: If-statements in Smalltalk (2008)

#35

Post by pg314 »

aaron-lebo wrote: post #33
pg314 wrote: post #20

Since if-statements are built out of blocks and message sending, you can easily do some cool things. One of them is building up an abstract syntax tree (AST) of an expression without parsing that expression. E.g. suppose you want to build up an AST of the statement (x Instead of starting with an x of type Number, you would start with an object of type ASTVariable, that responds to the message As an sexp: (ASTIfStatem…

Is this a bit like a runtime macro? Does it have performance disadvantages?

> Is this a bit like a runtime macro?

You can indeed accomplish some similar things with it.

> Does it have performance disadvantages?

A Common Lisp macro is evaluated once at compile time. In Smalltalk this is evaluated at runtime, so that adds some overhead. Usually you only have to build the AST only once though, and can use the result many times, so that overhead isn't really relevant.

Re: If-statements in Smalltalk (2008)

#36

Post by pozorvlak »

noobermin wrote: post #6

First, I did not know this, it's pretty cool. But, for all the fangled cool things that the more powerful languages of yesteryears (like lisp), what seems to actually precipitate adoption is simply history, not necessarily expressiveness/powerful abstractions, etc. See C, sh and friends, javascript. Arguably, python is one where its ease made it popular and it continues to develop language wise, albeit not without co…

FWIW, this is also the standard way of implementing if/then in the lambda calculus:

true = \x.\y.x

false = \x.\y.y

Re: If-statements in Smalltalk (2008)

#37

Post by taejo »

pg314 wrote: post #20

Since if-statements are built out of blocks and message sending, you can easily do some cool things. One of them is building up an abstract syntax tree (AST) of an expression without parsing that expression. E.g. suppose you want to build up an AST of the statement (x Instead of starting with an x of type Number, you would start with an object of type ASTVariable, that responds to the message As an sexp: (ASTIfStatem…

This technique is limited by the fact that it only works if all the messages are sent to x, rather than x being sent some message.

Re: If-statements in Smalltalk (2008)

#38

Post by noobermin »

jacquesm wrote: post #9
noobermin wrote: post #6

First, I did not know this, it's pretty cool. But, for all the fangled cool things that the more powerful languages of yesteryears (like lisp), what seems to actually precipitate adoption is simply history, not necessarily expressiveness/powerful abstractions, etc. See C, sh and friends, javascript. Arguably, python is one where its ease made it popular and it continues to develop language wise, albeit not without co…

> Arguably, python is one where its ease made it popular and it continues to develop language wise, albeit not without controversy. Currently about 7K lines into a python project and I'm getting more used to it but 'leaky abstractions' is a term that springs to mind at least 10 times per day if not more. I'm busy with tricky array type conversions to feed stuff from one library into another a lot more than I would ex…

I never said python continues to be a language of ease for all use cases, I am talking about what precipitated adoption, not whether it is the best language it could be. To be fair, its abstractions make things which are downright difficult in C easier.

My last statement referred to with python 3 and above, there is active development of the language's fundamental constructs. I guess there is active ES6 etc. C's newer standards aren't groundshakingly different from its original implementation.

Re: If-statements in Smalltalk (2008)

#39

Post by RangerScience »

pozorvlak wrote: post #29
RangerScience wrote: post #17

The "response by Ralph Johnson" link is dead: http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entr... :/

Thanks - I've noted that in the post.

Do you remember what the title of that post was? We may be able to track down a copy, given more information.

Re: If-statements in Smalltalk (2008)

#40

Post by RangerScience »

pozorvlak wrote: post #28
RangerScience wrote: post #16

Fascinating. An amazing point about design patterns, and yet... Declarative statements are a pattern in ruby - you see them everywhere (`attr_accessor`). They're library code - you're intended to write them. I can't imagine trying to write ruby without that pattern, and I can't imagine them not being a design pattern. Similarly - the MVC of Rails. The lines get way fuzzier, but you still might try to draw similar lin…

I was really trying to make a narrower point here - that there is a reasonable way to distinguish "part of the language" from "part of the (standard) library" - but I'll bite :-) attr_accessor, as it happens ( http://ruby-doc.org/core-2.0.0/Module.html#method-i-attr_acc... ) is implemented in C code, but one could implement it in Ruby, so I'd count it as part of the (standard) library, and creating accessors is just…

Oh, neat! It's always cool when the authors of content pop onto HN (I see from you karma you're new here, welcome!)

Yeah - I heard your point when I first read your post, but it took some more time and reading to understand it. It's a good distinction.

What I'm not getting is... So you've got a really precise and elegant line between "language" and "library", but it's not clear what the difference is between patterns and.... maybe idioms?

attr_accessor, has_many, and carrierwave's mount_uploader (to provide many examples) are all examples of a "pattern" (in the sense of a repeated thing, not a design pattern) in Ruby, but I can't determine what's then in need of "fixing" or what abstraction features could be added to remove the "pattern".

Post reply on HN