Hacker News Reader

Comment by soulbadguy | Hacker News Reader

It's interesting how different languages resonate so differently with each of us. I have tried a bunch of languages, and got pretty deep into ruby at one point in time when rails was the main web framework i was using. However ruby is probably my least favorite language. Most of the features which actually make ruby unique are exactly the one that turned me away and toward something like F# when i want funtional goodness, C++ when i feel adventurous and scheme/racket when i want dynamic language fix.

> Ruby is probably the most expressive programming language on Earth

I wonder if there is a generally accepted quantifiable definition of programming language expressiveness. Here the author seems to equate it to closeness to natural languages.

In my experience, ruby code is easy to write, but hard to follow without being familiar with the code base and it's idom. A lot of the information required to understand it is passed through implicit context.

View on HN

On the other hand, I find it extremely difficult to follow C# code. It's a lot of type gymnastics and dependency injection noise that makes it hard to understand where's the actual business logic.

Agree. However i think this is mainly an artifact of API/framework designed in the 2000 and 2010 with over-enginered and over used designed patterns from the GOF. Both java and C# have their root deep in enterprise land were those are still sadly too common.

Modern framework are a bit better.

And type gymnastics seem worth it on something like F#, but on C#, it feels a lot like bureaucracy with not a lot of benefit.

I dislike C#. Too much ceremony for me. I want type safety without a ton of boilerplate. Is there any compiled language that offers this? Or languages built for the web? Go maybe? Not interested in a whitespace sensitive language though.

What kind of boilerplate are you seeing?

If it's an old project, that's a given but the culture is changing and community is slowly accepting terseness and performance as key factors to consider when writing new code.

I would have say F#, but it's white space sensitive, and sadly pretty much a dead language by now.

Pretty much all the new-ish language have less boiler plate than C#/Java. Kotlin and swift are somewhat good.

> I dislike C#. Too much ceremony for me. I want type safety without a ton of boilerplate. Is there any compiled language that offers this? Or languages built for the web?

Scala might be what you're looking for. (Or Haskell, but that's a bigger leap). You can write code that looks like Python/Ruby (some libraries are quite symbol-heavy, but you don't have to use them; check out lihaoyi's libraries for some Python-inspired simple interfaces), but everything's fully typed. And it has an excellent JavaScript backend that integrates with typescript/definitelytyped for using web libraries.

Probably Go, yeah. I'm a big fan of Python and have really enjoyed learning Go.

But would Go really reduce the "ceremony" compared to C#? I doubt it. Just look at Linq (functional programming APIs in C#) and compare this to the typical Go approach with auxiliary lists and for loops! Or what about error handling? Or null safety? Not that cool in Go, I think.

What boilerplate? Just use var everywhere and the compiler will type it for you.

I think the main problem with C# is that even though you can write scripty “pythonic” C# since like 2010, people are still coding C# likes it’s early 2000s enterprise Java. The .NET library doesn’t help either, since it sets the “style guide” that many developers follow.

I would suggest Kotlin. It is concise and readable and the language itself is a bit leaner than C# (delegates are, in my opinion somewhat redundant, if there are first-class functions, for example).

> I wonder if there is a generally accepted quantifiable definition of programming language expressiveness.

If there is such a definition it would not fit into these sorts of conversations. I love Ruby but every time I see someone mention Ruby "expressiveness" it is never mentioned as a subjective fact like syntax feature count. Instead it is always closely tied to emotional feeling, assumptions, and intuition. "Ruby's expressiveness means it just gets out of the way and lets me code." I've probably said that myself a hundred times.

OTOH it is great for DSLs and metaprogramming, gives a taste of what the LISPers have always had. Maybe that is a good definition of "expressive".

[edit: added thought about DSLs]

> It's interesting how different languages resonate so differently with each of us

Because programming languages are, at the end of the day, for communicating with other people trying to make the computer do things. And people have different styles, ideas and preferences.

The computer doesn't care; it just wants some binary code to execute.

> I wonder if there is a generally accepted quantifiable definition of programming language expressiveness

In my opinion, expressiveness is used as the catchall, je ne sais quoi whenever someone likes a language and needs another bullet point to put in the "Pros" column.

It has a certain je ne sais quoi but I don't know what it is.

I don't think that tracks because the reason people like Go is due to it's lack of expressiveness.

It feels like expressiveness is the quality of a language to allow the programmer to change the behavior of the language constructs themselves. Python __getitem__ would be a good example allowing the programmer to control [].

> A lot of the information required to understand it is passed through implicit context.

This is the counterintuitive genius of Ruby/Rails.

Ruby projects need an idiom and Rails gives you a good one. If a team knows Rails and its conventions they are a good ways toward developing a shared understanding of how to build (certain kinds of) software. You become acutely aware that writing code is an act of communication.

Other languages, ones with certain kinds of type systems and where there is more explicitness, can create an illusion that coders don't need to do the work to develop a shared mental model of the problem and how to solve it. As long as it compiles, everything's OK.

But I think there is always information being passed through implicit context and if it isn't handled correctly then quality will suffer, one way or another.

> Ruby projects need an idiom and Rails gives you a good one.

I can't say i agree. Projects need idiom reflecting the particulars of said project. Rails as a framework, shouldn't impose idioms to the whole project.

But more importantly from my view is that implicitness is not a requirement to any of the idiom that rails imposes.

> Other languages, ones with certain kinds of type systems and where there is more explicitness, can create an illusion that coders don't need to do the work to develop a shared mental model of the problem and how to solve it.

Here again, i don't agree. I would be surprise to find any language designer trying to replace the need of a shared mental model. IMO, the point of a type system and explicitness is to make the sharing of the mental model easier. The type system make the space of possible software smaller and therefore eaiser to grasp. And explicitness reduce the need to keep things in one's head.

I don't think the GP was centring their comment on language creators, but on teams building software using a given language.

I feel that some teams don't spend enough time discussing the mental model required to contribute well to their codebase. I feel that type systems can hide this, and that people creating the types for a project forget to make a coherent, understandable model (either this, or I'm too junior with my typing and don't yet have the skill to infer a model from the visible types).

I also think this model-building work has two related aspects:

1. it's hard to do and hard to describe

2. one of the best ways, in my opinion, is to build comfortable abstractions that reinforce the model.. but that's even harder to do. It's easier to "enforce" than it is to "educate"; types and patterns get used to enforce structure first, rather than to explain the structure. To be honest, I only have a light grasp on this myself... I've just seen a few cases where a codebases chosen abstractions and patterns of abstractions help to reinforce a structure, but don't help to explain anything about that structure or the problem it attempts to solve

> I can't say i agree. Projects need idiom reflecting the particulars of said project. Rails as a framework, shouldn't impose idioms to the whole project.

I disagree pretty heavily. There are certain things where it may be valuable for a project to have it's own bespoke idioms or conventions (if it was doing something especially novel because that's what was necessary to solve the problem), but there's all kinds of decisions where this level of uniqueness actively harms a project, because it's not something that developers should be expending energy on. How to log data, how to deal with basic straightforward security concerns, how routing should work, how to connect to a database, how to run routine queries and get an object graph back are all boring problems with well established "good enough" solutions and no particular need to innovate, and expending cycles on those, either in initial development or when new people onboard is wasted time.

I can be pointed at almost any Rails repo and have a baseline understanding of where to find things on day 1. That is almost never the case with a Javascript project.

> I can be pointed at almost any Rails repo and have a baseline understanding of where to find things on day 1. That is almost never the case with a Javascript project.

And this is a problem that a type system doesn't fix. A type system can't tell you that all ACL logic is in the reporting subsystem for some reason or prevent two components from managing user state in incompatible ways.

But every project will need to violate the conventions somewhere. If you just made all of the rules a baked-in part of the language you'd end up with a very inflexible language.

There's a lot of power in encoding some things at the human level instead of the machine level.

> I wonder if there is a generally accepted quantifiable definition of programming language expressiveness. Here the author seems to equate it to closeness to natural languages.

I was going to make a similar comment -- it seems there might not be well agreed definitions of "expressiveness" here. I write most of my own projects in Haskell, precisely because I find Haskell to be extremely expressive, but I mean something different to "reads like English" (for which I think AppleScript is the closest example I can think of): to me, the expressiveness of the language is "how accurately can I describe my problem domain to the computer in a way that lets me naturally reason about it in code". I think this is mostly a function of the type system, not the particular syntax (e.g. allowing "?" in a method).

I am really interested in what other people consider "expressiveness" to mean, however.

> I wonder if there is a generally accepted quantifiable definition of programming language expressiveness.

I doubt it, considering "expressive" tends to only ever describe something that's subjective.

Reply on news.ycombinator.com