Live data from Hacker News

Pharo 9

pharo.org

211–220 of 232 posts

Re: Pharo 9

#211

Earlier quoted context omitted.

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.

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

Its not uncommon in dynamic OOP (or even object-first multiparadigm languages); it’s true in Python, Ruby, JS, and others.

Re: Pharo 9

#212
post #209

Earlier quoted context omitted.

I was not talking about everything being an object. I was talking about that claim being the key to being nice and comfortable. Many sibling comments, IMHO, miss the point of the parent and focus on the claim about python and js. Python and js could perhaps have been completely object based. It still wouldn't make them comfortable for many.

While Python wasn't born pure object based, it is definetly object based in its current version. Python 3.9.5 (default, May 27 2021, 19:45:35) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> x = 1 >>> type(x) >>> dir(x) ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod __', '__doc__', '__eq__', '__float__', '__flo…

I think you are replying to the wrong comment. That's not even my point.

Re: Pharo 9

#213

Earlier quoted context omitted.

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

> Unlike most OOP languages, it's true, and not just marketing, for Smalltalk to make the claim that everything is in an object. Its not uncommon in dynamic OOP (or even object-first multiparadigm languages); it’s true in Python, Ruby, JS, and others.

For example, in Python, are activation records objects you can manipulate? Seaside uses this in Smalltalk to implement continuations. If not, then not everything is an object in Python.

Re: Pharo 9

#214
post #208
post #203

Earlier quoted context omitted.

Equating OS and its ecosystem to a single language is not very wise approach I think. In any ways you are obviously free to find fresh and shiny OS of your liking and use it.

It surely is, UNIX and C are a symbiotic relationship, born out of each other, one in 1969, the other in 1972. I surely have, hence why I have gone back to Windows, where the focus is C++ and .NET, macOS where the focus is Objective-C and Swift (UNIX is there for historical reasons only), Android where the focus are Java/Kotlin and C++ (with Linux kernel being an implementation detail).

UNIX is not a thing anymore, nobody writes UNIX code. People use various compatibility layer or straight up use kernel abis. And they are all improving over time. So no they are not all stuck in 80s. Even linux kernel devs are willing to add rust code in the mix.

> Windows, where the focus is C++ and .NET,

Microsoft is huge organization they have multiple focuses. You seem to be mixing the kernel/userland layer and making very weird argument against UNIX(that nobody uses).

I am not familiar with COBOL is there any effort to improve COBOL?

Re: Pharo 9

#215

Earlier quoted context omitted.

There is a GTK3 backend now, hopefully that should make HiDPI work, support Wayland, etc. – depending on how it's implemented of course. Doesn't look like it's ready to handle all the UI (?) though – in the promo screenshot there's one GTK window on top of a more classic Pharo window (?)

Because GTK3 is so great on Linux, we should run it on macOS and Windows too... I don't know what they were thinking. As far as I can tell, Pharo UI history has been one bad (as in not pragmatic) decision after another.

It's the MVP of native GUIs. Should a purely-Win32-based UI arrive later, the additional work would at least be validated and trailblazed by the first Gtk implementation. You can't expect a small set of people do everything at once just because you want them to.

Re: Pharo 9

#216

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?

Maybe Smalltalk sounds old like COBOL. It's hard to re-kindle interest in old tech in the eyes of new devs. It seems every generation of programmers want to have their "own" tools, even if they're worse than the previous ones.

COBOL's big problem has always been verbosity rather than age. Fortran and Lisp are older yet both have a more positive image. Fortran and Lisp are each far more succinct languages than COBOL.

(Contemporary Fortran and Lisp have evolved a lot since their initial version, but the same is true of COBOL.)

Re: Pharo 9

#217

Earlier quoted context omitted.

An interesting project for devs is Glamorous Toolkit ( https://github.com/feenkcom/gtoolkit ) as an experiment/exploration of better dev tooling.

And, frankly, this just reinforces my overall opinion of Pharo. Pharo is really amazing, they've been working on it, actively, forever, and make great strides. But I'm convinced that Pharo is an amazing development environment and eco-system designed to make amazing development environments and eco-systems. All of the folks are putting work in to improving IDE to make a better IDE. They're on their, what, fourth(?) i…

There is certainly some truth to what you say. Threading is... just not (afaik it's a sort of green-threads thing) and UI is, as you point out, a crapshoot. However... ;)

If I'm going to write code for my own amusement, I want to work in Smalltalk and a Smalltalk environment. Ever since I first encountered it in the early 1980s, it's been my environment of choice. IMHO there's still no other programming environment that approaches the flexibility, liveness, debuggability, white-boxness of Smalltalk. To paraphrase Guy Steele, "All languages will evolve until they become Smalltalk". (Steele said something of the sort about Lisp.) That said, and jokes aside...

Where Smalltalk beats every other language environment I've ever worked with or seen is at exploratory programming: Programming where you don't quite understand the problem, the domain and/or the solution space. It's more a tool for thinking about problems and how to solve them than something for a fixed, final answer. I suggest, further, that a very great deal of software development is exploratory in nature, so using a Smalltalk is a win, at least until you've understood everything in sufficient depth to "just implement a solution". At that point go to something with better runtime performance, deployability, etc. by all means. Caveat being that sometimes (quite often, really) the exploration never, ever reaches a conclusive terminus, so you may want to stick with a Smalltalk.

tl;dr: Use Smalltalk to explore and understand, and then finally to deliver an executable, test-driven specification.

Re: Pharo 9

#218
post #208
post #203

Earlier quoted context omitted.

Equating OS and its ecosystem to a single language is not very wise approach I think. In any ways you are obviously free to find fresh and shiny OS of your liking and use it.

It surely is, UNIX and C are a symbiotic relationship, born out of each other, one in 1969, the other in 1972. I surely have, hence why I have gone back to Windows, where the focus is C++ and .NET, macOS where the focus is Objective-C and Swift (UNIX is there for historical reasons only), Android where the focus are Java/Kotlin and C++ (with Linux kernel being an implementation detail).

For me it is Windows desktop and Linux servers. So far I had no business case to develop for other mobile and somehow do not feel sorry for it as I am in no rush to bend over to things like approval from App stores etc.

Re: Pharo 9

#219

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.

From 1980 to the late 80s or so people were struggling just to get Smalltalk to perform at reasonable speeds on microcomputer class hardware, so saying 1980 isn't really fair. And most of the research that went into getting Smalltalk (and Self) to perform well on those platforms was then used to get Java to perform. In actuality, Smalltalk gave Java a headstart. That said, Smalltalk just doesn't in general "play well…

>people were struggling just to get Smalltalk to perform at reasonable speeds on microcomputer class hardware

I've heard this before, but it confuses me as apparently the majority of the systems at Xerox Parc (Window manager, word processor, etc. ) were written in Smalltalk. So how could these sophisticated GUI apps perform there but not on other platforms, was the hardware really so different?

Re: Pharo 9

#220
post #214
post #208

Earlier quoted context omitted.

It surely is, UNIX and C are a symbiotic relationship, born out of each other, one in 1969, the other in 1972. I surely have, hence why I have gone back to Windows, where the focus is C++ and .NET, macOS where the focus is Objective-C and Swift (UNIX is there for historical reasons only), Android where the focus are Java/Kotlin and C++ (with Linux kernel being an implementation detail).

UNIX is not a thing anymore, nobody writes UNIX code. People use various compatibility layer or straight up use kernel abis. And they are all improving over time. So no they are not all stuck in 80s. Even linux kernel devs are willing to add rust code in the mix. > Windows, where the focus is C++ and .NET, Microsoft is huge organization they have multiple focuses. You seem to be mixing the kernel/userland layer and m…

>UNIX is not a thing anymore, nobody writes UNIX code

Please, get out of the GNU cult and check out what BSD's are doing in C.

Post reply on HN