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

“The days of using untyped languages on non-trivial projects are over.”

github.com

Post reply on HN
Print view View original

91–100 of 117 posts

Re: “The days of using untyped languages on non-trivial projects are over.”

#91

Post by missingdays »

mikewarot wrote: post #88

The biggest problem with most typed languages is string handling, especially null terminated strings. Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes. Typed languages offer some efficiencies, and can, if properly used, help pr…

The biggest problem with a couple of typed languages is string handling. The rest are doing just fine in this regard

Re: “The days of using untyped languages on non-trivial projects are over.”

#92

Post by viraptor »

mikewarot wrote: post #88

The biggest problem with most typed languages is string handling, especially null terminated strings. Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes. Typed languages offer some efficiencies, and can, if properly used, help pr…

I'm so confused. What do you think happens differently in C#/python/Ruby/rust/whatever when you add one string to another? Or when you read into a buffer without a predefined size? Or assign one string reference to two variables?

Re: “The days of using untyped languages on non-trivial projects are over.”

#93

Post by nabogh »

danwee wrote: post #50

Agree with the sentiment (statically-typed languages are cool), but TS is not ideal. Is the best we have if you want something JS-like, but try to explain the following monstrosity to a junior colleague who's starting with TS in the context of web applications (using one of the most popular frameworks out there, NestJS): // a DTO that handles the creation of some kind of resource ... @IsArray() @ArrayMinSize(1) @IsSt…

Is that typescript's fault though? Seems like a nestjs thing

Re: “The days of using untyped languages on non-trivial projects are over.”

#94

Post by ilaksh »

Static typing can have advantages but that doesn't mean it's completely invalid to use a dynamic or untyped language. It's understandable if some people prefer not to be involved in those projects though.

But it's completely feasible to use dynamic languages for non-trivial applications. I think it's fair to say that Hacker News is not a trivial application and it's written in a Lisp dialect called Arc.

The biggest advantage of dynamic languages is probably that they are usually more concise. Which can lend itself to a more elegant expression of intent.

Another advantage might be more flexibility reducing the tendency to add boilerplate or a lot of schema-specific code. And I am aware that many people consider a lack of schemas to be the worst thing ever. But at least they are flexible.

And yes I am aware that static types can eliminate errors at compile time. Those types of advantages don't completely invalidate the use of untyped languages.

Re: “The days of using untyped languages on non-trivial projects are over.”

#96

Post by wellanyway »

nathias wrote: post #3

I hate TypeScript so much it's unreal. A MS trojan horse to try and own the full stack, I hope you'll all be happy when we won't be able to use any of our tools without complying to corporate linguistic standards and watching the mandatory 20m of commercials per code scope.

Naivety of people in software development is something else. Billion dollar corporation hired 10 token nonbinary people and people just forgot, if they ever knew the history.

Re: “The days of using untyped languages on non-trivial projects are over.”

#97

Post by jasmer »

tmpz22 wrote: post #4

It’s disappointing that a lot of arguments for typing fail to explore why untyped languages became popular to begin with and how those benefits can be maintained throughout the migration process through partial typing To complete typing. When typing is applied gradually throughout a codebase it can sometimes manifest as the worst of both world and a complete argument should at least acknowledge that as well as the im…

[dead]

Re: “The days of using untyped languages on non-trivial projects are over.”

#99

Post by G3rn0ti »

Biggest reason for the success of TypeScript is it aids IDEs in statically analyzing your code and providing enhanced autocompletion results like e.g. methods and properties. In dynamically typed languages this a much more difficult task and can only be approximated by applying some heuristics without actually executing your code.

This is definitely an advantage! No dispute here. But whether static types make programs safer and their architecture cleaner is something in need to be proven empirically. And as others already wrote: There is a reason why dynamic scripting languages became popular.

Re: “The days of using untyped languages on non-trivial projects are over.”

#100

Post by UncleMeat »

Sterm wrote: post #31
_dain_ wrote: post #7

Earlier quoted context omitted.

> why untyped languages became popular to begin with because for a long time there were no mainstream languages with a good enough type system.

Types slow you down. New work is first completed in untyped languages. People start using the work. People complain there aren't types. Types are added. Work is now slow in the language. New work is now done in another language without types. Rinse and repeat.

There are maybe some programs where "time to first run" is a critical metric. But where I sit we spend way way way way more time living with a program after it has already been written. This means maintenance, bugfixes, and refactors.

Even if what you say is true, I'll trade some initial coding time to buy more efficient maintenance.

Post reply on HN