This article has only one real tip: create a high school programming contest for it. The rest is evangelizing a specific language itself, which I won't mention to avoid fueling the gimmick. I think we've been had.

In general programming language preferences are subjective. We all think different. I've been in many many debates over language merit. The only language that would truly make one happy is one custom fit for his/her own head. I personally want something that leverages the database more so I don't have to do data chomping in code, nor reinvent the schema in code (DRY). I'd also like custom block-scoping so that one is not stuck choosing between OOP or FP etc. A code-block's scope would be programmer-defined. You could roll our own control and class-like constructs.

Actually some languages are meta (bend-able) enough to reshape almost any way you want, but then in a team environment, you have to face others' custom mind-fit code, which defeats the purpose.

Can someone with actual real-life in-production-for-a-while in-an-actual-company-with-annoying-customers-who-change-mind-all-the-times tell me about the refactoring story in Smalltalk ?

Sure, I know the IDE can change the signature of a function, and stuff like that, but is it enough to actually do broad refactorings with any level of confidence ("broad" meaning "the kind where you realize the next feature requests invalidate most of your previous design, as happens pretty much every time you get a new feature request ?")

Or are you still at the mercy of a whatever the Smalltalk version of a runtime error is, whenever you have - god forbid - made a typo somwhere ?

I'm deeply hating a certain "pretty fashionable" dynamic langage (that will charitably remain unnamed) for this kind of reason, and I'm not going to buy the "Supreme productivity" claim anymore from any language that requires me to double check every function call just in case I mispelled a word.

For starters: when blogging about the language it is good practice to always link directly to the primary resource for it.

I have to say this: I am the architect of Pharo (bah, the guy who has the responsibility of putting the pieces together and handle the releases). While I cannot do anything about it, I do not feel comfortable (and I know a lot if not all the members of the "core team" either) with this kind of "evangelisation". We love our little environment, and we certainly believe it has merits enough to be considered a player in the language ecosystem. We do our language with passion and conviction, but also with respect for other languages and programmers.

While the author has the right to do as he thinks is the best, please consider this is not how the team developing Pharo thinks and act.

The author gets you with some Pharo evangelizing in there, sneaky.

I'd really like someone from the Rust community (steveklabnik?) to write a history of the language/community and what decisions they took to grow. There's social and technical stuff that got people to go out and evangelize, which is half the battle - what they've really succeeded at is getting people to listen.

Does it has cross-platform? One codebase, multiple targets? That's how you evangelize any programming language. In today's environment where the customer wants his solution to work on all devices, the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart.

So far, IMO, there are zero programming languages that do this. Java comes closest but is like only half-way there, rest are either lagging behind or even don't even approach this. Also I hate Java, but that's my personal choice.

This entire article is nothing but evangelisation for Pharo. Misleading title, worthless post.

I’m not surprised either. The author only ever writes Pharo evangelicals that consistently fail to demonstrate any of the supposed benefits; we’re always to simply believe what is said.

Any body can show me buzz words. Nobody gets points for buzz words, not even for effort.

That’s patently not how one promotes a programming language.

PHP did not need anybody to evangelize it

Languages should stand or fall on their own technical merits. If you have to try and convince someone that language X is good (or bad), there is probably something not quite right.

I hated Go when it first came out. I grew tired of hearing about it. My friends tried to get me to use it. I refused. One day, I needed to write some highly concurrent code, read about Go Routines, tried it and was hooked. I've been using it ever since. No amount of selling/proselytizing could convince me (nor should it). The language itself did when I took a serious look at it.

On this note, I still haven't found a language that does broad refactoring as well as C# (with resharper) does.

From method extraction, to module, namespace, function renaming, to adding parameters to functions, it just takes care of it.

My suspicion is that Java does it as well (but I don't have experience with it), but every other language I've tried lags far behind it.

It's been really frustrating to be really getting into something then tripped up because it doesn't understand that when you're renaming Foo to Bar you also want foo.ext to become bar.ext. Or when you want to make foo(a,b,c) become foo(b,c) that it's the first parameter that needs removing (automatically) from all calls. Or even when transforming foo(a,b,c) to bar(b,c,d) that it can fix the calls with combined re-move and add parameter instructions.

Some languages are starting to catch up, but I've seen nothing that has come close to the productivity that C# has delivered specifically with respect to refactoring.

Can anyone recommend other language / IDE combinations that can deliver that kind of productivity?

(And I don't want to get into a discussion about whether that's misplaced productivity because it's better to write in a way that doesn't need re-writing and re-naming things all the time, because you might be right but it's one of those times that being right doesn't change the reality of the work environment.)

I think one of the hard things about making suggestions about how to do a thing like this is that it's unfalsifiable. I'm not suggesting that only things that are falsifiable are worthwhile, but like, let's take what you're saying here at face value: Rust was evangelized successfully. What we can't know is, could we have done a better job than we did? Did some of those choices that I or whoever else would suggest as a best practice actually harm the adoption of the language? How can we tell the difference?

Frankly, Rust is not the example I would take about successful evanglization: the numerous Rewrite It In Rust (RIIC) posts, the ones asking on an inquisitional tone why the project haven't been written in rust, or those who changed the topic to rust in unrelated discussion (that's literally trolling) that is happening in a lot of threads here are really off-putting.

There's nothing sneaky about it. Right at the start of the third paragraph, it says: "I’m a Smalltalk evangelist and Pharo is one of these languages."

The author is presenting one example, and pointing to a Pharo programming competition as the key exhibit. It's a pretty impressive competition, too. Impressive prizes. Impressive competition map and Pac-Man style game.

In fact, if you look around the same blog, you'll find a nice comparison to another competition called Battlesnake: https://smalltalk.tech.blog/2020/03/03/battlesnake-the-compe.... JRMPC seems to be a cut above.

Evangelization is "preaching"; it's essentially advertising or marketing.

There's no one way to preach or advertise. One can take a number of different approaches. Presenting technical information is one way, the most common way. It's how most languages are promoted. But most languages never succeed with this approach. Most languages never gain much mind share.

So the author has taken another approach, something that is seldom attempted. The programming competition is an original and clever idea.

I'm not sure how one can "demonstrate the benefits" of a programming language. Most languages have been used successfully in software projects (e.g., Crystal, Elixir, F#, Haxe, Julia, Nim, etc.). Does trotting out these projects prove anything?

PHP was in the right place at the right time back in the mid-1990s. It exploited the nascent web and gained a first-starter advantage. In other words, PHP lucked out.

Most languages need some luck to make it to the top. JavaScript lucked out with the explosive growth of SPA, circa 2010. Python lucked out with the explosive growth of data science and machine learning in the past decade.

Ruby lucked out with the Rails framework.

Java and C# were heavily marketed by Sun Microsystems and Microsoft, respectively. Objective-C and Swift were heavily marketed by Apple. Dart and Go were heavily marketed by Google. Rust had Mozilla. Kotlin had JetBrains.

PHP was evangelized by every website which mentioned it was built in it, including having URLs ending in ".php".

Similarly, C and shell were evangelized by every Unix installation, Javascript was evangelized by every website which used it, BASIC was evangelized by innumerable microcomputers which had a BASIC interpreter instead of an OS... the point is, the best evangelism is to tie the language to something useful. Make the language the way you get at the functionality of that thing. Python and R are both evangelized by tons of pre-written code which you can access most conveniently from those languages, for example.

Smalltalk is the language you use to get the value out of Smalltalk systems. The problem is that, for a lot of people, there's no next step: What do you use the Smalltalk system for? Very few have an answer.

The alternative is to make your language a better way to get value out of an existing system. Python spread in part by doing this to shell and Perl, and Perl spread in part by doing it to shell. Python isn't just a better Unix scripting language, because of its libraries, much like how Perl isn't just a better shell because of its libraries. However, it's one reason Python and Perl spread so effectively. Now, Go is trying to do it to Python and Rust is trying to do it to C++.

So tie your language to something big, or focus on displacing a language already tied to something big.

Because it was the right tool at the right time when the web was new and growing rapidly. VB-Classic was similar: it allowed building GUI's with a small learning curve when the alternatives were esoteric and muddled, and thus spread like wild-fire.

cheap hosters did.

>Languages should stand or fall on their own technical merits.

A nice sentiment, but not reflected in reality. It's valuable to evangelise languages because

  1. better awareness of their novel features can pressure more widely-used languages to adopt those features - like the addition of lambdas to Java, Python, etc. 
  2. otherwise you risk being stuck with whatever people know, forever. "Lack of fluency" is a technical demerit from the perspective of a project lead.

I disagree. Many languages are technically excellent, but not gaining much mind share. They languish in the job market. For example, at Indeed, Clojure has 393 job postings, Elixir has 430, F# has 156, Haskell has 419, Julia has 706, Lua has 562, and Nim has 81. These are for the U.S. at the time of writing.

Python has 76,979 job postings, Java has 72,743, and even lowly Perl has 14,802. Technical merit is not enough; those lesser languages need marketing.

The fact is, language adoption in the IT industry is very much a matter of luck, fad and fashion.

Just like working on large technical projects, there is much more to success than just technical merits. Software engineering is mostly a social endeavor, and so social factors count—I’d argue they count more than technical ones in a lot of cases. Things like:

* whether the technology fits the background of your team/org/company

* the community/official support of the technology

* the long-term trajectory of the technology

* how the technology fares when used with groups of engineers, instead of individually

* social proof

* how easy it is for the existing job pool to learn the new technology

* if the technology has strong documentation

And there are more. These are more critical to me than eg goroutines. (And Go is my go-to language these days.)

But would you have tried it if your friends weren't trying to get you to try it?

A language is a product, like any other. Before it can be used, it needs to be noticed by it's target audience. And to be noticed, it needs to be mentioned.

Your own example demonstrates this. If none of your friends had ever mentioned Go to you, and no one had ever evangelised it, how would you have known that it's a good fit for that problem?