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

Pharo 9

pharo.org

Post reply on HN
Print view View original

151–160 of 232 posts

Re: Pharo 9

#151

Post by Qem »

scroot wrote: post #135
StevePerkins wrote: post #124

Earlier quoted context omitted.

Smalltalk first appeared in 1972, and was a stable commercial product by 1980. Java didn't hit the market until over a decade and a half later. If you can't build adoption with a 15+ year head start, then it's not the next generation's fault. It just wasn't going to happen.

> stable commercial product by 1980 This is not true. Even the Smalltalk-80 Blue Book wasn't released until 1983. > If you can't build adoption with a 15+ year head start Historical context is important here. FOSS etc were not nearly as prevalent as they are now, and most major development environments had a price. The main Smalltalk players probably got it wrong by pricing out expensive licensing fees. But the head…

There was also the issue of "viral pricing". As the application was grown as a extension of the image, people were supposed in some schemes to not only pay for their own copy, but also for every copy of the software they wrote and shipped to customers, as it piggybacked on the original image. While free software thrived on copyleft, the first Smalltalks withered on "payleft".

Re: Pharo 9

#152

Post by gavinray »

I've often heard two statements online from older programmers.

  "Delphi/TurboPascal was the peak of developer productivity"
And

  "Smalltalk was the peak of developer productivity"
I've only been programming about a decade so both of those languages were long before my time.

Can anyone who has experience programming in Smalltalk share what was so special about it/what made it so productive to write programs in versus other languages?

It seems like this unique playground-VM thing makes it sort of unwieldy for non-graphical tools. IE can you use it for scripting tasks system, or for writing networked applications?

There must be something unique about Smalltalk for so many of it's developers to reminisce about it and claim it's been unparalleled since.

Re: Pharo 9

#153

Post by FpUser »

Santosh83 wrote: post #144
FpUser wrote: post #137

Earlier quoted context omitted.

For people who are actively using their smartphones for many tasks. They're in majority I guess. I personally use smartphone as a phone, off-line GPS, camera (when I happen to not carry dedicated one) and to control various gismos like drones. I do not use it for reading, viewing websites, computing, etc.

What about music and videos/films? I admit carrying a separate e-ink device is too much of a hassle, so I read books on the smartphone when am not at the PC.

It depends one's lifestyle. I have my own company and work from home for 20 years already. So the PCs with the big 4K screens are always around. When I go to my summer's office it is the same thing. So I read/watch videos from the PC.

Yes there were few situations when I knew I'd sit in a car and wait for someone for quite a while. So I downloaded book on laptop and read it. I tried reading from a smartphone but my brain simply can not digest properly from this size of a screen. When I read I follow the line but I also glance at the whole page. Not sure why but this is how it works for me.

Re: Pharo 9

#154

Post by goatlover »

aitchnyu wrote: post #46

>In Pharo, everything is an object. This purity and uniformity in the system and language design makes Pharo clean and comfortable to learn. Does this mean Python and JS meet the same definition and are as "clean and comfortable"?

Ruby comes closer than Python or JS with it's blocks and consistent object model (including primitives).

Re: Pharo 9

#155

Post by goatlover »

egeozcan wrote: post #55
aitchnyu wrote: post #46

>In Pharo, everything is an object. This purity and uniformity in the system and language design makes Pharo clean and comfortable to learn. Does this mean Python and JS meet the same definition and are as "clean and comfortable"?

JS is for me clean and comfortable, sometimes more than C# and for some others Python is, and everyone has their own answer to "what makes them so". Everything being an object may do the trick for you or not. I don't mind a marketing page (even for a programming language) being opinionated, as long as not borderline delusional.

Unlike most OOP languages, it's true, and not just marketing, for Smalltalk to make the claim that everything is in an object.

Re: Pharo 9

#156

Post by hota_mazi »

zabzonk wrote: post #77
a2800276 wrote: post #73

The page seems to be going out of it's way to not mention the word "Smalltalk". Does anyone have an idea why that is? Does Smalltalk have such a bad reputation nowadays or has someone trademarked the term?

I've noticed that as well - it's a bit strange given that Pharo is a fork of Squeak, which does proclaim its ST origins on its front page. I wouldn't say Smalltalk has a bad rep nowadays, but it used to be knocked for being too expensive (the cost of ST licences back when was beyond a joke), too slow, and producing nasty-looking non-native GUIs. These have almost all been fixed.

The animated screenshots on the website pretty much indicate that the Pharo GUI is still non native and looking very dated and ugly.

Re: Pharo 9

#157

Post by AceJohnny2 »

gavinray wrote: post #152

I've often heard two statements online from older programmers. "Delphi/TurboPascal was the peak of developer productivity" And "Smalltalk was the peak of developer productivity" I've only been programming about a decade so both of those languages were long before my time. Can anyone who has experience programming in Smalltalk share what was so special about it/what made it so productive to write programs in versus ot…

It's a very noisy datapoint, but compare performance VW Smalltalk to NodeJS:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

VW Smalltalk is between 2x and 27x times slower than Javascript.

And Pharo is slower yet than VW Smalltalk:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Nevertheless, as the front page the the Benchmarks Game is careful to mention, benchmark performance is 1) not necessarily representative of real-world performance and 2) not even always important in the greater context!

Still, it's sad that Smalltalk & company haven't received the VM optimization attention that JS has. What would our world look like if Brendan Eich had gone for Smalltalk instead of creating a language from scratch?

Re: Pharo 9

#158

Post by Qem »

gavinray wrote: post #152

I've often heard two statements online from older programmers. "Delphi/TurboPascal was the peak of developer productivity" And "Smalltalk was the peak of developer productivity" I've only been programming about a decade so both of those languages were long before my time. Can anyone who has experience programming in Smalltalk share what was so special about it/what made it so productive to write programs in versus ot…

It's better shown than told. Just see this: 7 minutes of Pharo Smalltalk for Rubyists - https://www.youtube.com/watch?v=HOuZyOKa91o

Re: Pharo 9

#159

Post by hota_mazi »

pjmlp wrote: post #103
asah wrote: post #100

Earlier quoted context omitted.

Smalltalk never really got substantial adoption...

Thanks Java :(

Java was an answer to C++, not to Smalltalk, which had already been dead for a while by the time Java started taking off.

Re: Pharo 9

#160

Post by xkriva11 »

hota_mazi wrote: post #156
zabzonk wrote: post #77

Earlier quoted context omitted.

I've noticed that as well - it's a bit strange given that Pharo is a fork of Squeak, which does proclaim its ST origins on its front page. I wouldn't say Smalltalk has a bad rep nowadays, but it used to be knocked for being too expensive (the cost of ST licences back when was beyond a joke), too slow, and producing nasty-looking non-native GUIs. These have almost all been fixed.

The animated screenshots on the website pretty much indicate that the Pharo GUI is still non native and looking very dated and ugly.

Most tools were modified to use Spec framework so they can use the native look (using GTK) as well as the non-native one. (plus, in future, Web and Console backends). This transition should be finished in the next release.
Post reply on HN