Fork me on GitHub
#other-languages
<
2016-05-25
>
borkdude07:05:22

@jsa-aerial: looks interesting, thanks for sharing

borkdude08:05:49

@jsa-aerial: just watched it. nice

tjg08:05:00

@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.

tjg08:05:14

(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.)

borkdude11:05:02

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.

martintrojer11:05:22

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

martintrojer11:05:40

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

martintrojer11:05:08

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

martintrojer11:05:39

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

martintrojer11:05:00

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

martintrojer11:05:16

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

borkdude11:05:54

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

martintrojer11:05:03

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

martintrojer11:05:22

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

martintrojer11:05:42

which is better? clojure.spec or Monads?

martintrojer11:05:05

> The answer my friend is blowing in the wind

borkdude11:05:46

you can have both clojure.spec and monads 🙂

martintrojer11:05:03

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

martintrojer11:05:09

But your milage will vary

borkdude11:05:12

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

borkdude11:05:07

@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.

martintrojer11:05:50

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

martintrojer11:05:55

but, might be for you

borkdude11:05:38

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

borkdude11:05:24

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

borkdude11:05:42

Right tool... hard problem.

borkdude11:05:38

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

sveri11:05:58

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.

martintrojer12:05:27

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

martintrojer12:05:40

and we have clojure backend

jsa-aerial14:05:20

@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.

martintrojer14:05:13

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

martintrojer14:05:31

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

jsa-aerial14:05:40

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.

martintrojer14:05:00

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

jsa-aerial14:05:02

I disagree that 'most objections' concerned C++

jsa-aerial14:05:37

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

jsa-aerial14:05:54

4 is still debatable

martintrojer14:05:56

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

martintrojer14:05:15

I'd say it be far greater a number

jsa-aerial14:05:29

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

martintrojer14:05:52

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

jsa-aerial14:05:55

keyword typos would be in his type errors as well

martintrojer14:05:59

Sure, C++ and Java sucks

jsa-aerial14:05:46

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

martintrojer14:05:04

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.

jsa-aerial14:05:12

and 5 has nothing to do with dynamic vs static

jsa-aerial14:05:32

Unless you claim static can't be as expressive

martintrojer14:05:35

I have a very wide type-error bucket tho

martintrojer14:05:42

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

martintrojer14:05:52

but I am faster / better in a typed language.

jsa-aerial14:05:52

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'.

martintrojer14:05:56

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

martintrojer14:05:18

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

martintrojer14:05:42

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

jsa-aerial14:05:53

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

martintrojer14:05:32

Counting resported issues in GH vs langauges is quite misleading

martintrojer14:05:45

ignoring bug-reporting culture in communities etc

martintrojer14:05:56

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

martintrojer14:05:18

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

martintrojer14:05:26

The answer is always; 'it depends'

sveri14:05:14

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.

sveri14:05:39

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

sveri14:05:57

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.

sveri14:05:07

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)

martintrojer14:05:39

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

martintrojer14:05:02

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

jsa-aerial14:05:18

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.

jsa-aerial14:05:36

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.

martintrojer14:05:09

its cost / benefit.

martintrojer14:05:25

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

martintrojer14:05:38

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

sveri14:05:50

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

jsa-aerial14:05:06

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'

martintrojer14:05:06

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

martintrojer14:05:18

and they cripple the company

martintrojer14:05:39

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

jsa-aerial14:05:47

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