C# 9, 10…

[Mike Austin]

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/lambda-improvements

Improvements in a language are nice, but the language just gets bigger and bigger, to the point you can never master it. C++, Kotlin, Scala, Swift, … start removing features instead of adding them.

[Raoul Duke]

yeah, my naive dream is for there to be a good set of primitives without arbitrary restrictions. seems like the lambda c# example is about removing fixing old limitations. cf. i guess like how python lambdas suck. if things were less bespoke in the first place...

funny how many languages claim to want such simple but no simpler design, i think of scala in that regard, oy veh. 

in statically typed languages i hazard to guess there's even more 'reason' to have exceptions, limitations to the rules as "good enough for now" until someone smart can fix it later. swift's evolution includes fixes like that. 

[Kyle Hayes]

Some of the changes are simplifications.  The problem is that you have all the other cruft that developed around the initial hacky state.   As an example I present exhibit A, C++.  "Modern" C++ has many features that can help you write fairly safe code that doesn't leak resources and is relatively thread safe.   But it also has bare pointers, pointer arithmetic, direct access to POSIX APIs, etc. etc. from its early years.

Some languages, Go IIRC, have invested in tooling that will take an old codebase and bring it up to a more current standard.   C++ clearly has not.

"Can't break old code," is probably the single largest source of tech debt and language complexity.  How do you burn down tech debt in the form of old code you do not own?  How can you simplify when someone, somewhere used the complicated forms?

Even if tooling like Go's is not 100%, as long as it does 99% of the job and makes the burden a lot less, people at least have the option of moving forward.  Most companies will not because people are almost always short sighted about this, but at least the possibility is there.

Trying something that looks about right, and iterating to polish it works just fine in most other types of programming.  But not in language design apparently.   At least not if you have a user base.

Best,

Kyle

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pilud/CAJ7XQb7Er838rs3SjN3o%2B3nfjCABVVgsvrwwqpoizWeM_%3D_%3DnQ%40mail.gmail.com.

[Mike Austin]

I like the Go idea of automatically upgrading, although I expect it could be a scary change if it updates lots of code. And then on the topic of backwards compatibility, you have Python 3.0, which as Raul points out, has it's own issues.. it's now a new language.

[Kyle Hayes]

I agree.  You are dependent on someone else to make sure that the transformation applied to your old code to make it new code is correct.  Without any proof of which I am aware.  The flip side of that is that most Go code is pretty simple on a line-by-line basis so the potential for non-obvious breakage is lower than some other languages.   At least the Go people are trying.

Python was bad planning IMHO.   Many of the backward-incompatible changes they could have introduced one at a time (spreading out the pain) and had guarded by feature flags.  If they had followed Java's approach where the underlying bytecode was strongly backward compatible but the high level syntax wasn't, then you could have different modules with different versions of Python.

Best,

Kyle