Hacker News Reader

Comment by wbond | Hacker News Reader

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code.

As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

View on HN

I think what's important is that they are making good choices, such as immutability, take fewer lines of code. This pulls the default developer in the direction of writing immutable by default, which I think is great change.

As I write more and more code, the more I want simplicity

I had a 24 year old developer report to me that apparently thought his bonuses were tied to how many operations he did on a single line of code.

He consistently wrote unbelievably complex lambda expressions with multiple conditional operators that would make a single line take up at least 1.5 screenfulls in Visual Studio on a 1920x1080 resolution monitor. These lines were impossible to debug and had to be inevitably broken up.

For a while I thought he was following the conventions laid forth in:

https://www.thc.org/root/phun/unmaintain.html

...but he really seemed to be genuinely thinking he was accomplishing something good by doing this.

I'm with you though. I'll take simplicity.

Well it depends how you do it. There's certainly some mileage in doing it like that properly:

http://blogs.msdn.com/b/lukeh/archive/2007/10/01/taking-linq...

Over the board or just expressive? http://programmers.stackexchange.com/a/261893

Ha! "Exploit Compiler Name Length Limits"

I worked for many years on a FoxPro application with a 10-character limit. The first version of the program was written under a two character limit. This never bothered my boss, who was a terrible typist and always used short names anyway. But I at some point took up the practice of descriptive names, on top of the Hungarian notation we'd adopted for sanity. So I was exceeding the limit all over the place.

Ten years later, guess who had to convert the program to VFP, which has no variable name limit. And no compile-time checks on variables, even when they are declared. Glad that year's over.

That's fascinating, because Steve Yegge suggests that density tolerance is a factor of skill. http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm...

Isn't that what the APL/J/K people keeps saying? I guess sometimes it makes sense to optimize for hunting deer rather than optimizing for special forces ops (Even if spec. ops. probably are fierce deer hunters...).

On the other hand, Steve Yegge and people like him (ESR for one) always suggest that whetever they like is "a factor of skill".

I'm with you, both for your reasons and for another: it makes code harder to teach. "Oh, you'll see this. And this. And this . . . There's this, but no writes it that way. This is idiomatic."

There's some of this in all languages, of course, but "this bit of sugar will make the code cleaner and easier to read" assumes that everyone will adopt a new set of idioms wholesale (which they usually don't).

I have spent a large portion of my career teaching new developers. I think C# is a pretty terrible first language already. The sugar here and there is nothing compared to the massive mental burden of OO, inheritance, compilation, DLLs, Visual Studio, etc etc etc.

Scheme, via SICP, is much easier to get started with, and one can learn the basics with that quickly (including getting much more comfortable with the sequence abstractions -called LINQ in .NET- than even the average .NET developer).

All these reasons are also why I greatly prefer F#. If you stay away from much of the OO system, F# is much simpler to teach in my experience. At my company right now another team is putting together an F# training program intended to teach our QA automation.

The vast majority of these changes are very understandable. The only one that is complex is the ? operator, which compresses only code that is very uninteresting and harder to read.

Comparatively the string trick, read-only properties and lambda syntax for simple methods seem very easy to digest.

>>> the more I want simplicity and ease of understanding over typing a few less characters

True, coming from Java where you have to type a lot to get a simple thing done I seem to be gravitating towards languages which have clean, simple syntax that allows you to actually think about the problem. I've been playing with python and scheme, I'll have a go with C# soon, now its been open-sourced.

Go would fit that definition quite nicely as well. It may be worth adding to your list of things to check out.

Better do it before checking out C#....

Thanks exch and pjmlp, I will check out Go before C#

I was being sarcastic, because you will be disappointed if you learn C# first.

>While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code.

Syntactic sugar can be that, but not THIS syntactic sugar they propose here.

Here it makes the code easier to read and the intent more clear.

There is an optimal level of complexity per line of code that you should try to keep constant throughout your project. It's like a meal, I'd rather have something light like a salad and some soup over eating a 1 lb bar of chocolate for dinner.

Reading code should be like reading a nice book.

Manager: "Why isn't the project done yet? Why are you still coding?"

macromaniac: "Patience, I'm still working on salad..."

Most of the features make the language more consistent and reduce syntactic noise, making it easier to read. The only feature that puts additional mental burden is the elvis operator.

Don't even try F# then :). Syntax is terse, but so academically alien.

Reply on news.ycombinator.com