Hacker News Reader

I think that part of the problem is to define data structures in a way that can be produced and consumed in multiple languages, algebraic data types are a good "least common denominator" for this.

Also w.r.t. reinventing the schema for databases, I have got a lot of mileage out of deriving the schema from code. Shameless plug, I have this little project (https://github.com/Morgan-Stanley/hobbes/) where we have a self-contained header-only library to push structured data out of process with minimal latency, query data concurrently with a Haskell-like PL. It works well for our kinds of systems (millions of orders per day, ~1 billion market data ticks, structured log data from multiple systems involved, ...).

Attributes are usually easier to share than functions and algorithms. That's why I suggest using "data dictionaries" nearby. Most common CRUD idioms are readily attribute-able such that we don't need Turing Complete sub-languages for majority of them. We just need useful code "hooks" to customize when needed, which is the usual bottleneck of attribute-driven development.

One way that I feel comfortable with is publishing clear, real life-ish examples of what can be accomplished in the language by playing on it's strengths. Debating merits never really leads anywhere, all languages have strengths and weaknesses, all languages are compromises in some respect.

I've put quite some effort into the DRY database schema problem over the years. The only reasonable way forward that I've found is defining the schema in code and creating the database from that definition. SQL is a definitely more primitive and limited than most programming languages, so it makes perfect sense to generate it.

And the only way to truly custom fit a language is to create it [0].

[0] https://github.com/codr7/gfoo

Rather than rely on SQL, why not put the common info in tables? A "data dictionary" (DD). If tools can extract or sync that up to the actual schema, that's a great bonus, but is not a prerequisite. Using things POC annotations is ugly and hard to track.

And we don't have to rely on the DD to do everything. Of course intricate business logic should be in app code, but app code shouldn't reinvent the obvious things like minimum length ("required"), max length, field description, synopsis (longer "help"), display order, key type (primary, foreign) and their related "look-up" references, etc.

I've found that if the DD results can be intercepted by the program, then it's more flexible. It should have an event that allows the DD attributes to be programmatically altered per screen, and then another event to modify or remove the actual HTML and/or SQL generated from the those attributes. I call it "staged rendering". This allows the DD to do 90% of the grunt work, but not limit local customization. Local customization has been the most common bottleneck of past DD-based attempts.

I like it when computers do the grunt work; that's what they were invented for. Our current common CRUD stacks violate data-related D.R.Y. up the wazoo and nobody seems to care as long as they get a paycheck. Auto code generation is only a half solution because once you alter the copies, you can't rely on generators anymore: they wipe out your custom code.

Interesting.

I never use annotations in my own tools, I add first class abstractions for whatever database features I need and free form records to shuffle data. So there will be something called a Table, with Columns and Keys. It's not so much reinventing as bridging, an FFI doesn't reinvent the library it imports.

And yes, that means you can't modify the database from the bottom any more. But you're not losing any power, since any random programming language is more flexible and convenient.

Most databases come with some kind of built-in DD, I've used them in Firebird & Postgres to read primary- and foreign keys while I was still investigating the approach.

But it never really clicks for me, because the database is not the software, it's where the software stores its data. Tying application logic and presentation to the relational structure of the data just doesn't make any sense to me.

> This article has only one real tip: create a high school programming contest for it.

Yes, but this "tip" was demonstrated by an example. The example is a Pharo-based programming competition, so it's reasonable to say a few words about Pharo. Otherwise, the article would be pretty darn brief!

> Otherwise, the article would be pretty darn brief!

It is pretty darn brief. The title and first few paragraphs would lead one to believe that the article is going to be about programming language evangelisation.

Instead, it's nothing of the sort. It's nothing but a dishonest segue into listing the author's favourite merits of Smalltalk/Pharos then briefly mentioning the programming competition.

No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry.

None of that.

The mention of the competition is literally in the last two paragraphs, the last of which is only one sentence.

Let's be honest: this isn't really an article at all. It's clickbait, and we've all been had. It attempts to write a cheque it can't cash.

> No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry.

That was your expectation, not mine. You were led to believe one thing; I interpreted this article differently.

Sure, for some people, the title could be seen as clickbait. I didn't see it that way.

The author did present information, just not the information that you wanted. He pointed out that most language evangelization depends on technical publications and GitHub repos, and that this hasn't produced the desired outcome. That's practically axiomatic! Just look at where Clojure, Crystal, Elixir, F#, Haskell, Idris, Julia, Nim, Pony, and Ring are. They're still struggling for relevancy.

In the third paragraph, he states: "I’m a Smalltalk evangelist and Pharo is one of these languages." There's nothing dishonest here. He's presenting Pharo and the programming competition as a sample case study.

Once you dive into the linked article, you learn all you need to know about the competition.