Clojurians Log v2

This is something that is really worth taking in: https://vimeo.com/74354480

@jsa-aerial: looks interesting, thanks for sharing

@jsa-aerial: just watched it. nice

@jsa-aerial: Thanks, just watched it too. I suspect there's a large space for meta-programs (ones which take your program as input) to help you, and static vs dynamic is just one of many possibilities.

(One reason I like the lisps is because of that promise of meta-programming... coding in data structures seems like an important step to that, at least for practical engineering reasons.)

Maybe it's better to go the route dynamic -> static -> dynamic, so you know for certain why you use it and not just as a given.

good talk

a bit unfair to paint all static languages as bad and use C++ as proof

(I do agree, C++ is worse than cancer)

The metrics of 'what is a type error' can be argued ofc. I'd put all null related bugs in there aswell.

The argument is; there is no silver bullet, use the right tool for the job, use the right tool for the team.

The fact is that people are different, and some work better with a type system and some don't.

One big mistake is to claim that dynlangs are better "because I think so"!

@martintrojer: I agree. What I'm wondering is: is the preference for dyn. or static learned behaviour or really something personal

the truth is that there is no winner here. we're all on a jouney

some teams kick butt in F#, some in Clojure.

which is better? clojure.spec or Monads?

> The answer my friend is blowing in the wind

you can have both clojure.spec and monads 🙂

To get specific, I can only speak of my own (recent) experience, and that tells me that Elm >> CLJS.

But your milage will vary

However I'm not a big fan of monads in Clojure. Feels too unnatural.

@martintrojer: In isolation I can imagine, but with a backend in Clojure it's just too easy to build it all in the same language.

same language FE / BE is irrelevant for me / my team

but, might be for you

some project I've worked in, it would be a major win if some guy didn't start what is now 200k lines of AngularScript what could have been 10k lines of cljs

but then again, I've built a Clojure front/backend that could have been built with RoR even quicker probably

Right tool... hard problem.

what I like about clj + cljs is that you can pass values back and forth without thinking about it too much

and to add more to @borkdude point, I can even define schemas in .cljc that I can reuse in clj / cljs which is another major win. And as soon as spec is ported to cljs the same is possible there.

I don't dispute that is useful. But in my case totally irrelevant.

and we have clojure backend

@martintrojer: I think you are bringing some baggage there. Smallshire didn't paint static languages as 'bad' (nor equally that dynamic languages are 'good'). And he didn't use just C++. The well done F# example is a significant piece of the talk. And his statistical analysis included F# and Haskell in it. And, as he points out, C++ had the 'best' results - because it is used (tested) by all the others, since so much of it is at the bottom of the stack.

Agreed. I just came away feeling most objections on static langauges was using C++

Sure, he found the case when F# units-of-measures broke the laws of the universe

IMO, there are several real take aways from this. 1) that a real (HM) type system will pass a (reasonably well done) type construction and produce wrong results (F# example). In a sense this is not much of a surprise since these systems can't be both sound and complete. 2) We need to get beyond 'good' and 'bad' and simply realize that the hard data (such as there is) shows zero evidence for any effect on robustness wrt static vs dynamic. 3) 'type errors' constitute an extremely small percentage of errors. Again, not too surprising when you realize that most errors concern domain semantics and types don't really capture that well or in most cases at all. 4) Static tends to complect the elements of a system, where in the limit, you end up with a monolithic artifact. 5) Expressivity is far more important in robustness and productivity.

Agree with many of those points, but not 3, 4 and 5

I disagree that 'most objections' concerned C++

Hard to disagree with 3 (1-2% is small - 98-99% are not type errors)

4 is still debatable

His categorization of type errors was far too narrow IMHO. I'd include all null related stuff there, keyword typos in clojure etc etc

I'd say it be far greater a number

5 has real evidence from all the studies - admittedly these studies are small and not a good signal

4,5 suffer from haskell, ocaml, F# etc not being part of the studies

keyword typos would be in his type errors as well

Sure, C++ and Java sucks

they were part of his github study and if you look at severall other studies, haskell is often included. So, this is incorrect

keyword types leading to nill wouldn't be in his numbers (I might have misunderstood). But in my personal experince, type errors are the vast majority in (mine my teams) clojure bugs.

and 5 has nothing to do with dynamic vs static

Unless you claim static can't be as expressive

I have a very wide type-error bucket tho

I'm only offering an opinion here, what's true for me. I'm not claiming its universally true.

but I am faster / better in a typed language.

I think what you are really saying is 'belief'. That's one thing Smallshire (and others) has pointed out as a sad state of affairs - there are few (and not significant in scale etc) real studies giving hard evidence on this stuff. Peoples claims largely boil down to belief - or as Smallshire puts it 'religion'.

I don't dispute the scientific 'hard' data -- just wished it was a bit more up to date

but I do disagree with his categorization of what is a type error.

Re; religion, I guess. Writing code is still a by-hand artisan trade.

My belief (!!) and fear is that you just can't create good scientific studies at the scale needed to get a signal from the noise. If there is to be any good evidence, I think it is going to have to come from data mining stuff like github. So, in that sense his (admittedly not well controlled) study is in the right direction

Counting resported issues in GH vs langauges is quite misleading

ignoring bug-reporting culture in communities etc

But, if we get scientific / put money into it. It'll probably still be a wash

I don't think you can prove that either is better.

The answer is always; 'it depends'

I want to point at: http://research.microsoft.com/apps/mobile/news.aspx?post=/en-us/news/features/nagappan-100609.aspx which showed the the two most significant factors for bugcount are TDD and the structure of the organization a team works in.

I also think that static / dynamic never showed a big benefit in either way.

Also it might be that Haskell has a good HM implementation, but, if I imagine that all my colleagues would have to learn Haskell (myself included here) and have to become as productive as we are now, it would take months to years, for sure.

Its nice to have a good type system, but, if I think of the last months of my work, none of the problems I had would have been hit by a type system (OSGI / classpath problems mostly)

agreed. A big bias is what individuals you've got in your team. How the team works, and their experiences.

If the team is working, language doesn't really matter

Of course naive 'counting' in github is not good enough. That's obvious but irrelevant to the point, which is that things like github are the only place where you have enough data to work with.

As for $$ for real studies, you won't find anyone willing to throw (literally) millions at this. Actually probably 10s of millions to get real at scale controlled studies across all manner of variables involved.

its cost / benefit.

Lets say microsoft did this study and dynamic came out on top.

what would they do? force the office team to switch from C++ to http://VB.NET?

Looking at the M$ study I would not even think about static / dynamic, but instead enforce TDD for all teams and think about how to improve my organizational structure

Yes, but the problem here is the cost is to a single (or small group) while the benefit would go to others. This is a classic govt type thing, but again, the numbers involved pretty much guarantee no agency (NSF, DARPA, etc) will dump that level of $$ at this in the current 'climate'

the thing is that the software teams are tribal. If the bosses forces a F# team to swtich to Clojure they'd all quit.

and they cripple the company

so even if a massive study came out saying dyanmic is slightly better, nothing would change

Certainly nothing would change any time soon. In the long run maybe