Earlier quoted context omitted.
Why is Java one the of really awful ones? I know Java is not the best language, it's not my favorite language, but I wouldn't say its really awful.
Two words: no functions.
Java has functions one word "static".
Is Typed Clojure worth the trouble?
41–50 of 62 posts
Re: Is Typed Clojure worth the trouble?
#42Earlier quoted context omitted.
Do you have any evidence to prove this? I've read a few papers that disagree with your opinions...
That's the thing though, there are lots of papers that support both sides of the argument out there. For example, take this http://macbeth.cs.ucdavis.edu/lang_study.pdf large scale study of GitHub projects. In the study, Clojure is right up there for correctness with hardcore statically typed languages like Haskell. There's plenty of software written in both typing disciplines in the wild. Yet, nobody managed to conc…
I agree with this comment of yours but the first one has a few overstatements and that prompted my reply.
Also if you feel that strong types slow you down I suggest you try some gradually typed language where you can start out without types, do the exploring and add the types when you know what you want. I've tried this in TypeScript and it was a fairly good experience.
Re: Is Typed Clojure worth the trouble?
#43Earlier quoted context omitted.
Two words: no functions.
Java has functions one word "static".
You can't pass a static method as an argument to another static method. You can't write a static method that returns a static method. You can't partially apply a static method. Static methods are not functions.
Re: Is Typed Clojure worth the trouble?
#44Earlier quoted context omitted.
Java has functions one word "static".
You can't pass a static method as an argument to another static method. You can't write a static method that returns a static method. You can't partially apply a static method. Static methods are not functions.
Yeah, it do not have closures
Re: Is Typed Clojure worth the trouble?
#45Type checkers are an automated solution for the problem of not having good teammates. If you don't have that problem you won't benefit that much from type checking and might have many other huge advantages.
That's nonsense frankly. I've worked with an excellent team of Haskellers before I don't think we'd have been anywhere near as good without the type system. I'd agree that having an awesome team gives you a lot of other advantages, and actually FP is a huge opportunity to build that team for start ups. FP tends to attract the kind of people who make up a great team. It's for this reason that I think the conclusions o…
Thanks for the downvotes, I was referring to things beyond FP. The type system is a set of early restrictions (as opposing to late restrictions or runtime or late bound).
But now you mention it, I'm curious about if you think the type checker allowed you and your team to reach the goals of the project faster or not.
Re: Is Typed Clojure worth the trouble?
#46Type checkers are an automated solution for the problem of not having good teammates. If you don't have that problem you won't benefit that much from type checking and might have many other huge advantages.
I don't think you understand the benefits of type checkers. Here are some: - Catching at compile time errors that would otherwise happen at runtime - Performance - Occasionally, it can enable making your code mathematically, provably correct - Maintainability and flexibility in the sense that the code is easier to read by future hires - And the most important advantage of all: automatic refactorings. Without that, th…
I know of at least 3 dynamically typed systems that can rename a method automatically in the whole system in one click. And move instVars to super and other tricky things like that before Eclipse was in the womb.
I'm talking do those refactorings in year 1999.
Re: Is Typed Clojure worth the trouble?
#47Type checkers are an automated solution for the problem of not having good teammates. If you don't have that problem you won't benefit that much from type checking and might have many other huge advantages.
Even the smartest teammates in the world won't protect a program from that idiot who wrote all the code in my personal projects. Good type systems minimise the damage that he can do.
I get your point so type systems are a protection for bad hires, a perceived as defense mechanism on code.
But things should never reach not even close to that point.
Re: Is Typed Clojure worth the trouble?
#48Earlier quoted context omitted.
that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats the problem?
More like its FKF (Fear of the Known and Familiar). Most (if not all) programmers have experience with static typing and most of those experiences were not pleasant hence why a lot of people don't like static typing. People start to hate it even more when it gets shoved down their throats i.e. "You must absolutely must use static typing otherwise your software is unreliable and buggy". Static typing requires discipli…
That's a good observation
Re: Is Typed Clojure worth the trouble?
#49Earlier quoted context omitted.
that is static typing FUD. if it takes you a few days or weeks to learn to use the type checker and it saves you from expensive runtime errors later, then whats the problem?
The problem is the overhead in adding typing. The time taken to learn the type system is a one-off but static typing has running costs in slowing down development, discouraging exploratory programming, extra cognitive load in reasoning about the type system, and "false positives" in disallowing otherwise correct programs. It does nearly eliminate a class of bugs - this is wonderful, but the bugs it does eliminate ten…
That's a really important point. Lots of time sunken in confirming the compiler that could have been used in exploratory programming. Humans are fundamentally explorers not conformists.
Nice duality you exposed right there!
Re: Is Typed Clojure worth the trouble?
#50Earlier quoted context omitted.
The keyword being "some". I've rarely had any problems with null/nil reference errors in Clojure, because nil is treated both as false and as the empty list, so most of the time you do the right thing in case of nil. You also don't call methods on objects, but send values to functions, which eliminates a large source of NPE right there. Clojure is also a compiled language. So things like calling a function with the w…
> most of the time you do the right thing in case of nil I can't remember where, but I was just reading something yesterday to the effect that a solution that works most of the time is worse than a 'solution' that never works: at least you'll notice the latter quickly, whereas you might not notice the former until it's buried so deep in your code that you've forgotten the hidden assumptions it involves.
Well can't be taken seriously. Real life works most of the time. Only theoretical thought experiments could work all the time.
Can you show me a clock that worked more than 10K years?
They are still trying to invent one (and we're not having it yet)