Hacker News new | past | comments | ask | show | jobs | submit | more tfha's comments login

The way many people read code, it's much easier to overlook three characters than it is to overlook three lines with indentation.


That's quite an interesting, if frightening, take on it. Assuming a developer knows what `map` does, then I wouldn't have very much confidence in their reading comprehension if they somehow mentally skipped over the main higher order function being called on a three word line of code.

Would anyone expect such a developer to read and parse several more lines of code more reliably, in order to understand the algorithmic complexity? Seems unwarranted to me...


Humans make mistakes. People code review after exhausting days or late at night. Or sometimes they skim more than they intended to. You want to make problems in the code obvious everywhere that you can.

In programming, if you miss an important detail the repercussions can be high. In a million line codebase every idiom that's slightly more complex than it needs to be is going to result in dozens of additional bugs, sheerly because of the increased surface area for making mistakes with that idiom.


I agree with everything you've said here but being mentally exhausted doesn't make it more likely that you can read even more lines of code in a more reliable fashion.

I think the clue to your thinking, for me, is in your description of the `map` HOF as "slightly more complex". Having years of experience with both paradigms, I've found that grokking a call to one of these fundamental building blocks (map, filter, reduce, fold, etc) is nearly instantaneous. We've all experienced reading prose where the author was excessively verbose when the same point could have been made succinctly. It feels the same way reading for loops once you get over the learning curve of these very basic functional constructs. You have to keep repeating that boilerplate endlessly and it's very tedious to keep writing and reading it.


> Humans make mistakes.

Yeah, and it's much easier to make mistake with a loop than with a map or filter.


That's really strange to me because I find go to be very readable. There are so few approaches to each of the basic programming building blocks in go that once you have read a moderate amount of idiomatic go, everything else just feels easy.


There are far more readable languages in go. Go also encourages nested conditionals which can become a nightmare to trace when you're under duress.


Maybe I'm missing something but Go _discourages_ nested conditionals. There are even static analysis tools in the idiomic toolkit which tell you when your conditionals can be simplified.


No it doesn't, quite the opposite actually. Go favours "exit early" strategies


I'm only responding to my parent post's arguments. I don't know much about Go myself.


I find other people's go code is generally much more readable than other people's code in most other languages.

Go's simplicity and heavy idiomatic culture means all the code more or less looks identical. This is great for team projects.


I'm honestly of the opinion that this shouldn't be allowed either. Accept that you need to name the variable 'fooErr' and just ban all shadowing


> Parallel construction happens way less frequently than people think it does

This seems like a rather vague claim


I used to be a public defender before I went into corporate and tax practice. Out of roughly 100,000 cases that went through the local PD office while I was there, fewer than 10 involved parallel construction.

Including the two neighboring counties, out of nearly 750,000 criminal cases during that time, only about 3 or 4 dozen involved parallel construction, and most of those were gang cases in which the parallel construction involved one of the gang members turning on his homies.

It's big news in local legal circles when the prosecution tries to use parallel construction to get evidence into the record because it happens so rarely.

It does happen more frequently at the federal level, but they also have significantly more resources to conduct investigations along parallel paths.


Those are the cases where the parallel construction was caught, right? What about all the cases where parallel construction was used and successfully kept secret?


Fees are not a significant part of a libraries revenue


Yeh I guess that is why it was easy for them to experiment with it.


Nah sometimes you need to resize manually read a webpage. Gotta keep usability at least a little bit. Letterboxing I think is a good compromise


I don't think Ajedi32 disagrees with you. I think Ajedi32 is saying that in addition to the all the resolutions that are a multiple of 200x100, a few more resolutions should be allowed, such as 1920x1080.


Before patents, businesses depended fully on trade secret, meaning developments would be made and lost over and over, and progress on a particular technology would be a lot slower because nobody could ever build off of eachother's work.

The patent system today is not really what it was meant to be, but the original patent system I think was an improvement over the status quo of the day.


That is not true. In fact the case if the steam engine highlights how harmful patents are. When the patent expired the amount of innovation flourished.

Patent law, like many other economic interventions relies on claims and arguments that have little to no evidence.


Nah I'd flip the complete opposite direction. Responsible use of psychedelics has many strong upsides, and I think the outright ban has done a lot of net harm to society.

At the very least I think doctors and researchers ought to be able to prescribe them and run experiments.


Yeah I have several permanent overhangs from my experiences with psychedelics as well. At one point I did 500+ug of LSD in a single trip and I am still working through PTSD from some of my delusions.

That said, the net effect on my life has been massively positive and has directly contributed to me being comfortable with myself, my body, my mind, my friends, and my place in this world.

Despite the overhangs, I highly recommend psychedelics as well. Though maybe stay under 400ug :)


When you say PTSD, would you mind expanding on how that manifests? Is it a low level constant anxiety, or more akin to sudden anxiety due to a certain trigger, or something else? I understand if it's too personal a topic. I'm very interested in psychedelics, but am worried about the potential negative side effects. Someone I know said LSD caused them anxiety once, and it lasted for a few months but eventually sorted itself out. Is your PTSD sorting itself out slowly? How long ago was your 500+ug experience?

Also you say you have some permanent overhangs; would you mind telling me a bit more so I know what to expect?


Trigger oriented, usually related to existential feelings of emptiness. Asking the question "does my existence have meaning" for a long time would spike my pulse to 150+ and cause me to freeze up. Took maybe 18 months to wear off fully. I can still psyche myself out if I try today.

Other triggers were anything that seemed too unlikely to be reality. Waking up with 11111 karma on Reddit, strangers winking at my like they could read my thoughts, things of that nature.

It honestly wasn't that bad to live with.

After my 4th trip I had really sharp HPPD. That burn in effect you get when you stare at something for a minute plus, that took about 0.5 seconds for me. And then it took about 60 seconds to wear off. For about 2 weeks I had a constant triple or quadrupole or more image burned into my eyes. Eventually I learned to cope by shifting my eyes every 0.5 seconds like a crazy person, but it did stop the after images from accumulating.

That went away after maybe 3 months, hasn't been a problem since.

My advice would be to space out trips 12 weeks or more to avoid hppd, and stay under 400ug to avoid PTSD and crazy delusions. And if you are inexperienced with LSD really you should start at a dose of 150ug or so.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: