HNHacker News
TopNewBestAskShowJobs

ReflectedImage

476 karma · joined May 12, 2020

submissionscomments
ReflectedImage··on Trump says Venezuela’s Maduro captured after strikes
MAGA at its core is a rejection of the lower classes having wealth.
ReflectedImage··on Trump says Venezuela’s Maduro captured after strikes
Replacement? They haven't overthrown the Venezuela government just captured it's figure head.
ReflectedImage··on Why C++ programmers keep growing fast despite competition, safety, and AI
Well I don't think anyone would pay for the COBOL to Java conversion software.

Since it's no longer New Years Eve, I'm a bit more sober :p

Programming language to programming language conversions seems to be one of the things LLMs are actually good at. Whether they can actually do it or not is an open question.

CEOs will mandate security so the CSOs will mandate Rust over C/C++ and so Rust will slowly take over C++ in next 20 years. Can't see anything in C++'s defense other than it's legacy. The drawback of sticking every feature from every language into your language is that it becomes a massive security hazard.

huh? I'm currently at $1500 Monthly Recurring Revenue, so I'm currently between seeing if I can increase that or if need to get a job. I'll find out in a couple of months.

ReflectedImage··on Why C++ programmers keep growing fast despite competition, safety, and AI
Well it's in Windows, Linux and Mac OS kernels. So you moving into Retro computing?
ReflectedImage··on Why C++ programmers keep growing fast despite competition, safety, and AI
Yep, not a single line left. Retired quicker than COBOL. Won't even be any maintenance jobs for legacy systems left.
ReflectedImage··on Why C++ programmers keep growing fast despite competition, safety, and AI
Have you heard of Microsoft's C++ elimination plan? They are building an LLM based transpiler that automatically turns all C++ code into Rust. In a couple of years, there won't be a single line of C++ left... Isn't that wonderful?
ReflectedImage··on Why C++ programmers keep growing fast despite competition, safety, and AI
The military isn't going to allow C++ anymore due to it being a massive security hazard. You can't get away with buffer overflows, use after frees, data races, etc. forever.

Due to an evil entity called the military industrial complex, you are going to be using Rust in the future.

ReflectedImage··on T-Ruby is Ruby with syntax for types
If JITs hadn't been invented you would be completely right but JITs have been invented.

There are deeper optimizations that JITs can do such as knowing at runtime that the value of a variable is always 2 that typing information simply can't express.

Duck typed Python is optimal for development speeds, the only thing that matters in startup environments. It has it's niche.

You aren't gradually improving, you are gradually deteriorating the codebase to make it look more familar to you.

ReflectedImage··on T-Ruby is Ruby with syntax for types
The problem is there are a lot of developers who have only coded with static typing and have no idea about the terrible drawbacks of static typing.

They don't understand what static typing does to code verbosity and development times.

Take Turborepo going from Go's typing light system (designed to emulate duck typing) to Rust's heavy typing system (true static typing). Originally the code was 20,000 lines and was coded by 1 developer in 3 months. When moved into the typing style you like so much, the same code is now 80,000 lines and was coded by a team of developers in 14 months.

ReflectedImage··on T-Ruby is Ruby with syntax for types
Absolutely not. Duck type based development results in working code out of the door 3x faster than static type based development. It always has since ancient times.

If performance wasn't an issue, then the static type based developers would all be fired. Either directly or by the businesses who relied on them getting driven into bankruptcy by their competitors. You would still get some niche jobs in it where they like to do formal verification of the code.

Your problem is just that your development skills from static type based development don't transfer to duck type based development. Different style of codebases needs to be handed completely differently.

ReflectedImage··on T-Ruby is Ruby with syntax for types
Yep, the software development slows down to crawl. Yes, you can still code at the same speed as you were coding in a language like Java or C# but that is considerably slower then what's possible in languages like Ruby and Python.

To give you a roughly idea, you should always expect a 3x slow down when using static typing.

An recent example is Turborepo that went from basic types in Go to proper static typing in Rust. Just adding in the proper typing caused the codebase to grow from 20,000 lines to 80,000 lines and from 3 developer months to 14 developer months.

The stronger your typing system, the slower you will develop code. Whether you realise it or not.

ReflectedImage··on T-Ruby is Ruby with syntax for types
"Wasteful unit tests that assert your types are right"

You don't test whether the types are right, you test if your code actually does the right thing. That's what's important to your customers.

The types getting tested is incidental.

ReflectedImage··on T-Ruby is Ruby with syntax for types
Static typing doesn't have much value if there are proper unit tests. So it's fairly obvious that if people think there is value in static typing then they are shipping broken code to their customers.

It's called ratting yourself out.

ReflectedImage··on T-Ruby is Ruby with syntax for types
And that's the problem, if you want your code to actually work you do need to write those unit tests. A program not crashing doesn't mean it does the right thing.

With experience you will learn to either write unit tests or spend the same amount of time doing manual testing.

Once you start doing that then the unit tests just replace the static typing and you start shipping better code to your customers.

ReflectedImage··on T-Ruby is Ruby with syntax for types
Nah that's just a lack of understanding in the role of unit tests in dynamically typed languages.
ReflectedImage··on T-Ruby is Ruby with syntax for types
Gradual typing is the worse of both worlds.

You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.

ReflectedImage··on T-Ruby is Ruby with syntax for types
Making the type annotations pass restricts you to writing more bloated and verbose programs in general.

Stating that A is an integer isn't much of a issue but once you get a reasonably complex program and A now has a compound type made of 5 parts, it really does slow you down and it really does make you write considerably worse programs for the sake of passing a type checker.

Any commercial code will need to be unit tested so there is no time saving from finding runtime errors earlier and an any good IDE will detect the same errors and provide you with the same auto complete automatically for free without any type annotations at all. These are problems which exist solely in your head.

1 developer vs a whole team of developers. I think you need to face the facts.

There are studies comparing old dynamically types languages against statically type languages. They always show approximately 1/3 of the lines of code being used with 3x faster development times in the dynamically types languages. This isn't some new discovery.

Well even Python is strongly typed but for the sake of this we are discussing type complexity.

ReflectedImage··on T-Ruby is Ruby with syntax for types
I'm comparing a program with itself.

Go only has basic types and interfaces to emulate duck typing (structural typing). The type complexity in Go is rather on the low side of things.

ReflectedImage··on T-Ruby is Ruby with syntax for types
Type free languages like Lisp, Python and Ruby have faster software development times than languages that use types.

The developers who are using the statically typed languages, which are slower to develop in, with are being pushed to use the faster languages.

But those developers don't know how to code in type free languages. So they attempt to add the types back in.

This of course reduces the software development speeds back to their previous speeds.

This means the whole thing is basically folly.

If you want a real example you can take a look at Turborepo, which in weakly typed Go took 1 developer 3 months to develop and has 20,000 lines of code. The direct port to Rust took a team of developers 14 months to develop and has 80,000 lines of code.

Exact same program but the development costs went up proportionally to the increase in the strength of the type system.

There are plenty of developers out there who have only used static typing and don't understand it comes with massive software development costs compared to it alternatives.

If you are developing a SaaS and you use duck typing, unit tests and micro-services. You will get to market long before your competitors who don't.

ReflectedImage··on Announcing the Beta release of ty
Types are not always useful, they increase the line count per delivered feature by 3x to 4x, which results in a corresponding increase in bugs in the delivered code and an corresponding increase in the overall software development costs.

It's very foolish to just use types in all programming projects.

ReflectedImage··on Announcing the Beta release of ty
No one can do fast prototypes with types, all they can do is convince themselves they are faster than they really are.

Having worked in both dynamically typed and statically typed software development shops, the statically typed programmers are considerably slower in general. Usually they only have 1/3 of the output as programmers who use dynamically typing. Statically typed programmers also tend to be much less ambitious in their projects in general.

They still think they are "fast programmers" but it's complete fiction.

ReflectedImage··on Announcing the Beta release of ty
Yeah, but that doesn't exist. Types and fast development are directly opposing goals.

This goes all the way back to Lisp vs C in the 1980s with C programs having triple the development time as Lisp programs.

To modern day with Turborepo taking 3 months to write in structually typed Go vs 14 months in statically typed Rust.

ReflectedImage··on Rob Pike goes nuclear over GenAI
Never heard anything about what you are talking about. There isn't a charge for using tropes, plot points, character designs, etc. from other people's works if they are sufficently changed.

If an LLM reads a free wikipedia article on Aladdin and adds a genie to it's story, what copyright law do you think has been broken?

ReflectedImage··on Rob Pike goes nuclear over GenAI
Well a creative type can be defined as an entity that takes other people's work, recombines it and then hides their sources.

LLMs seem to match.

ReflectedImage··on Rob Pike goes nuclear over GenAI
But is it meaningfully different from the outsource to India craze?

That certainly in the short term took some programmers jobs away. That doesn't mean it pans out in the long term.

ReflectedImage··on Rob Pike goes nuclear over GenAI
And this is different from outsourcing the work to India for programmers who work for $6000 a year in what way exactly?

You can go back to the 1960s and COBOL was making the exact same claims as Gen AI today.

ReflectedImage··on Rob Pike goes nuclear over GenAI
Gen AI taking programmer's jobs is 20 years away.

At the moment, it's just for taking money from gullible investors.

Its eating into business letters, essays and indie art generation but programming is a really tough cookie to crack.

ReflectedImage··on Rob Pike goes nuclear over GenAI
All creative types train on other creative's work. People don't create award winning novels or art pieces from scratch. They steal ideas and concepts from other people's work.

The idea that they are coming up with all this stuff from scratch is Public Relations bs. Like Arnold Schwarzenegger never taking steroids, only believable if you know nothing about body building.

ReflectedImage··on Announcing the Beta release of ty
Speaking as a Python programmer, no. Using types in a prototyping language is madness.

The point is you drop things such as types to enable rapid iteration which enables you to converge to the unknownable business requirements faster.

If you want slow development with types, why not Java?

ReflectedImage··on Microservices is the software industry's most successful confidence scam
But don't forget OOP was an attempt in the 90s to bring micro-services to single user computers.
← PreviousPage 2 of 19Next →