7 ms·
> IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions > Most of the time when I review code my remarks is: it shoul
by thethimble 6y ago
> IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions
> Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each?
Java is an extremely poor example of a helpful type system. Consider OCaml, Haskell, Elm, and others which avoid much of the verbosity you describe.
Static typing is really helpful when doing refactoring. The fact that a statically typed program compiles gives you important assurances - especially post-refactor. It's not a silver bullet but it's also certainly not "playing tennis with the compiler" as you describe.
- romanoderoma 6y ago> Java is an extremely poor example of a helpful type system My point exactly! Most of them are. Java is not special in this regard. C? bad COBOL? bad C++? bad Pascal? bad Rust? better, but somewhat confusing Go? not particularly good, but at least it's very simple C#? same defects Java has etc. etc. Statically typed languages IMO are like turbo charged engines, if you are an expert driver you could go way faster, granted the road is in good shape, but if you are not, you'll crash, possibly in a horrible way. > The fact that a statically typed program compiles gives you important assurances - especially post-refactor. The only assurance in most of the statically typed languages is that code compiles, not that it works.
- smabie 6y agoHow about OCaml, Haskell, Scala, or F#? All have pretty decent type systems, with Scala and Haskell even supporting higher kinded types. I'm at the point where I refuse to write production code in a language that doesn't have an expressive type system. Dynamically typed languages are even worse.
- romanoderoma 6y agoThe worst code I've ever seen in my life are Spark scripts written in Scala. Scala is so complicated that people use only a fraction of its features, usually the simpler ones. It takes a real commitment to become a prolific Scala programmer. > Dynamically typed languages are even worse. I don't comment on personal taste, everybody has their own.
- yawaramin 6y agoSo, you've never seen production-grade Scala application code?
- romanoderoma 6y agoAs I've already said here (https://news.ycombinator.com/item?id=24614064 https://news.ycombinator.com/item?id=24614064) there are people like you that assume that their background is the only background possible. Scala is complex, writing production grade Scala requires skill not common, it is like asking regular commuters to only drive F1 cars. Would everyone go faster or there would be more crashes? Would you blame drivers for the crashes?
- yawaramin 6y agoI know Scala is complex. Many languages are. No language starts out with the goal of being complex. They all want to be simple and elegant but the clash with real-world use-cases makes them complex. Like Bjarne Stroustrup said–there are languages that people complain about and there are languages that no one uses.
- smabie 6y agoHave you considered maybe your problem is simply that you don't understand Scala? I used to be a professional Scala dev and loved the language. Sure, there's some complexity, but I still strongly believe it is the most powerful and expressive static language around.
- romanoderoma 6y agoHave you considered maybe the problem is that I know Scala enough to know when it's bad? (I studied Scala at EPFL with Martin Odersky as professor)
- nephanth 6y agoSeeing your messages, I really think you don't mean the same things as the others when you say "strong type system". Generally what people here mean by strong type system is ADTs, inference, type-checking, pattern-matching... All those tools are made to help the programmer write better, safer programs more easily, as well as lay out his thought It is generally associated with FP, and are fond in languages such as Rust, Ocaml, Typescript, Haskell, F# From what your examples are ( C, java, C#...) and the drawbacks you see (too much getters -> linked to an OOP style of programming), what you mean by "strong type systems" looks like it is the old C-style type systems (+ OOP though I don't really get what oop has to do with type systems). These systems are not mainly intended to help the programmer but are really meant ro help the compiler. When in C you write `int a;` What you're doing is indicating to the compiler that for operations involving variable a, it should use the machine instructions for operation on integer (you can replace C with java and machine with jvm...). These are necessary in order to have low-level control, but are not really hepful (apart from, maybe, documentation purposes. It is always useful to know that that ipv4 variable is a 24-bit int and not a string...) These two types of systems are tremendously different things. I can really understand that you don't like static type systems if you only know the second type of system, which basically only adds constraints. I think you should take a look at ocaml, or perhaps haskell, it would probably expand your horizons
- pron 6y ago> Java is an extremely poor example of a helpful type system. With generics added 15 years ago, lambdas with argument type inference 6 years ago, local variable type inference two years ago, and ADTs and pattern-matching [1] gradually rolling out already, Java is practically becoming an ML. I say that as someone who likes both ML and Java. The two are becoming so similar that I think it's a stretch to claim one of their type systems is more helpful than the other. But I think people overlook type systems' biggest benefits. Empirical observation has not found any significant benefit to correctness in general (although there seems to be some in particular cases like JavaScript vs. TypeScript and I wouldn't be surprised if we find it in Rust vs. C), but the main benefits are code organisation and tooling support (refactoring, code completion). [1]: https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html
- romanoderoma 6y ago> , Java is practically becoming an ML For new code, yes. For old code, it's more in the realm of COBOL Also given that is one of the few languages that can speak fluently with technologies that are not very well known anymore, but still rocking many boats like SOAP webservices or AS400 mainframes The bulk of the Java applications are inside banks and insurance companies > are code organisation and tooling support (refactoring, code completion). Agree. Even though code completion has never been a problem for me in the past 20 years, not even with bash lately
- pron 6y ago> it's more in the realm of COBOL If you're talking about programming style, I don't see the resemblance (have you seen COBOL code?), and if you're talking about usage, then Java is much more popular and used in many more domains than COBOL ever was. If you must compare it to anything, then the C of large server-side software would be a more apt comparison, I think. > The bulk of the Java applications are inside banks and insurance companies And Apple and Google and Netflix and Amazon and Alibaba and governments and militaries and telcos and cedit card companies and airports and power plants and factories; wherever you'd find big, mission critical server apps, really.