Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cold Showers

github.com

Post reply on HN
Print view View original

351–360 of 363 posts

Re: Cold Showers

#351

Post by benhurmarcel »

southerntofu wrote: post #280
tlamponi wrote: post #269

Earlier quoted context omitted.

no idea of $ but say they'd get 5000€ a month (quite OK for most places europe), the company would need to pay out a bit more here (for some tax/social benefit things), 7000€ would be pretty realistic, so 4 developers could be hired. This then means that while op wouldn't immediately add 1M ARR, the original dev and the new devs could soon add 5M ARR (stupid extrapolation, it won't be as much in practice, at least no…

Please note that in many places 5k€/month is a huge sum of money for a salary. Even in western Europe, and in France more specifically, many devs i know are payed 1-2x minimum wage (i don't know a single IT person earning 5k€/month although i'm aware they exist). In France, minimum wage is about 1500€/month (before taxes), to which you add about as much professional taxes and contributions from the employer. Accordin…

You need to account for the total cost to the company, not just the before-taxes salary.

In France a young developer easily costs €100k/year to employ, even if he earns a third of that before taxes.

Re: Cold Showers

#352

Post by camgunz »

ehnto wrote: post #309
laserlight wrote: post #128

> Hype: "Identifiers should be self-documenting! Use full names, not abbreviations." > Shower: Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging. That's a very weird take on the statement. The downside of using abbreviations is probably dominated by the…

Maybe I could get it done in the same time, but I'd be really annoyed, and less certain what things are intended for. An IDE can really carry the burden figuring out what things are, but you're going to lack some context. Usually it doesn't matter WHAT things are, I need to know WHY you have a variable, and what it's intended use is. That can be explained in the variable name a lot of the time. I have the same argume…

> Why did the API endpoint change? ...

This stuff all feels better suited for a commit message. Conversely if I found all this in code I'd delete it.

I'm an almost never comment person (I use them when things are weird or inconsistent, but otherwise view them as noise) but I've been persuaded by John Ousterhout that code cannot adequately describe abstractions, and you need comments to fill in the gap.

Similarly with variable names, if you don't know i is index, please don't try working on this code. I get some code is a soup of inscrutable variable names and flow control to the degree it looks decompiled, but that's a higher level composition problem, not a "use more nouns" problem.

Re: Cold Showers

#353

Post by camgunz »

SmooL wrote: post #161
WalterBright wrote: post #149

Earlier quoted context omitted.

People nearly always gravitate towards abbreviations in natural language. The more a word is used, the more likely it gets shortened. LA for Los Angeles, Frisco for San Francisco, Vicki for Victoria, Jay for Jason, Dub for George W Bush, Doozy for Duesenberg, and on and on. Why should programming be different?

Because abbreviations are nice when there's a shared context that is perpetually "in memory" - I don't have to think to know what LA stands for. However, that is not the case when debugging. It is almost certainly the case for the person who wrote the code originally, but it is certainly not the case for the next person to come read it afterwards. IMO code is meant to be read, so I try to never use abbreviations (oth…

Shouldn't you have some shared context when working on code together, even at different times? Maybe they terms of art, maybe it's a style guide, but there oughta be something.

Like, isn't it fine to change:

    var basicAuthenticationController = new BasicAuthenticationController()
to:

    var ctrl = new BasicAuthenticationController()
I find that if code authors do work upfront to contextualize things for me that it helps tremendously. Like do I need to know at every point that this is a BasicAuthenticationController? Or is this the basic auth module and we're always dealing w that controller? I prefer it when engineers set the table for me like that, it helps me narrow my focus to the purpose of the code.

Re: Cold Showers

#354

Post by gpderetta »

semiquaver wrote: post #343
jacobsenscott wrote: post #342

Earlier quoted context omitted.

Typescript, swift, and certainly rust are not common languages by any stretch of the imagination. https://www.tiobe.com/tiobe-index/

If you really think TIOBE is a reasonable way to gauge dev mindshare, fine. 1. Python with mypy has `strict_optional`. On by default. 2. C, being “portable assembler” is not really statically typed. 3. Java has had Optional for years, although it’s not the most pleasant to work with it does exist. And JVM languages like Kotlin go well beyond this. 4. C++ has `not_null`. 5. C# supports type-system enforced non-nullabl…

> 4. C++ has `not_null`.

Most importantly in C++ only pointers can be null. You can return value types that are not nullable.

Re: Cold Showers

#355

Post by gpderetta »

jacobsenscott wrote: post #117
cloogshicer wrote: post #14

> Static Typing reduces bugs. At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and helps in navigating the program. It's a tool for thinking and communicating.

I've never found static typing to aid in my understanding of a program. For example: def add_item_to_cart(item) vs void add_item_to_cart(IItem item) They are equally easy to understand. The first is easier to read.

Static typing does not imply type annotation. For example in C++:

  void add_item_to_cart(auto item)
will still statically verify that item has the required syntax; C++ is very poor on this aspect on only doing the verification at instantiation time, languages with more sophisticate typing systems can infer the correct type from tome add_time_to_cart definition alone.

Re: Cold Showers

#356

Post by tene »

jacobsenscott wrote: post #342
tene wrote: post #274

Earlier quoted context omitted.

> no commonly used statically typed language helps here because they all allow null references This is false. TypeScript, Swift, and Rust are commonly used and support non-nullable references. > those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway. You don't need escape hatches to deal with…

Typescript, swift, and certainly rust are not common languages by any stretch of the imagination. https://www.tiobe.com/tiobe-index/

Dunno what to tell you dude; my imagination stretches there just fine. Maybe consider going to imaginary yoga class.

There have been people writing at least two of those languages everywhere I've worked for a while. Most of my professional colleagues can write at least one of these comfortably. I'm extremely confident in being able to hire programmers for all of these. They're all in use at every major tech company.

If you really want to stick your head in the sand and cry about how nothing can be better until they're literally top of the charts, I can't stop you, but they're certainly not rare. There's good stuff out there. Lots of people are using it. You can too.

If you'd rather trade links to charts, I trust Stack Overflow's developer survey's methodology a lot more than TIOBE's. 30% of respondents said they've worked with TypeScript, and that jumps to 36% in the professional developer subset. Rust is 7%/6%. That's a hell of a lot more than 10 developers.

https://insights.stackoverflow.com/survey/2021#technology-mo...

They also got 15% of developers who aren't using TypeScript want to use it, and 14% for Rust:

https://insights.stackoverflow.com/survey/2021#most-loved-dr...

My country has about 15% black people about about 7% asian people. My country has about 4% LGBT people, and my city has about 15% LGBT. It would be really weird to hear someone say that black, asian, and LGBT people are not common, especially after knowing and working with plenty of them.

Re: Cold Showers

#357

Post by lijogdfljk »

jacobsenscott wrote: post #340
lijogdfljk wrote: post #328

Earlier quoted context omitted.

I don't need tests to check what methods or fields are on my types though. You need the same tests from a typed system in a non-typed. You _don't_ need all the tests from a non-typed system in a typed system. Writing tests to enforce types just hand-rolls a type system, in my experience.

> I don't need tests to check what methods or fields are on my types though. You do though, because invariably people violate the LSP and just "throw Unimplemented" in the methods required by the interface they can't figure out how to implement. In other words all system are duck typed in reality.

I don't, though. If it compiles, it exists. Saying that a method might actually be a nuke is a bit besides the point. It could also contain a virus.

Not sure what typing system you're referring to, but it sounds very half-baked at best. I'm using Rust fwiw.

I cannot access any field or method that does not exist. Even dynamic traits are compile time enforced, but i think we can largely have this discussion around static dispatch.

Re: Cold Showers

#358

Post by tene »

jacobsenscott wrote: post #341
tene wrote: post #264

Earlier quoted context omitted.

With static types, every function signature implicitly comes with built-in tests for free.

Not true because anyone can implement just part of an interface and throw "method undefined" for the methods they can't figure out how to implement. This happens all the time.

The only time I have ever seen something like this is using `todo!()` while initially writing code. I have never seen someone check in code like this.

What kind of clown show of a programming org are you working at?

This is morally equivalent to "There's no point to having a safety on a gun, because the safety won't stop you from bashing someone in the face with the gun." If you really want to, you can throw exceptions or crash the process or call exit() or call system("shutdown -h now") anywhere in your codebase. That has nothing to do with a type system.

Re: Cold Showers

#359

Post by klysm »

repsilat wrote: post #103
klysm wrote: post #68

Earlier quoted context omitted.

Refactoring with confidence that you didn’t forget somewhere.

Yeah, a common mode when I'm making changes is "add a field to the type, run the type-checker, fix all the failures." In a sense "type coverage" is analogous to test coverage.

I use this workflow so frequently - writing it the first time is harder but, changing it is so much easier that it’s absolutely worth it to me.

Re: Cold Showers

#360

Post by klysm »

Gigachad wrote: post #150
klysm wrote: post #68

Earlier quoted context omitted.

Refactoring with confidence that you didn’t forget somewhere.

This is the major one. I work on a 10 year old rails app and it has got to the point where we are terrified of making any change that has the potential to affect areas outside of the visible git diff. It's easy enough to manually verify regular changes by looking at the code. But something like a library update is impossible to verify and we constantly end up with production issues because of something changing in a…

Sounds exactly like every dynamically typed code base I’ve ever worked on. Even if it’s not big. If you can’t grow out all the parts that matter (which is a lot of the time), you are screwed.
Post reply on HN