@agile_geek @seancorfield @mccraigmccraig I continue to be very glad that I looked at Scala, thought “that’s neither fish nor flesh” and decided to go with Clojure as my intro to Functional. I am still struggling to get Clojure into my working life - people want me to do “other things” and I have trouble finding anyone remotely interested in me as a Clojure developer 😞 - but I am always going to write Clojure code. Clojure is the single most rewarding programming environment that I have ever used.

💯

Yes, learning Scala is certainly a valuable exercise. It’s an interesting approach to that particular space (i.e., what might a "better Java" do to help folks move to FP gradually — while still appealing to "enterprise" shops).

I get the impression Odersky has learned a lot from Scala out in the wild — and the Dotty work on a next gen type system seems like progress to me.

(although I don’t track the Scala world very closely these days)

My "Intro to Functional" happened in the early 80’s — I’m very happy to have a viable JVM language for FP in the "real world" these days...

Has anyone used Javaslang or AOL Cyclops? These two complementary libraries bring monadic approaches into Java. You get some of the USPs of Scala without some of Scala's baggage. I also like that Javaslang replicates Scala collections. It's been heavily influenced by Scala in that respect. I like those libraries as I can still use mature Java tools whilst still getting to use Scala features I like without having to use Scala. Of course if I could use Clojure in my day job that would be a different story all together.

@maleghast I suffer the same issues with using Clojure in my professional life. I'm working on a plan to try and develop a client who will let me develop something under my terms at the moment but timing seems to be conspiring against me.

@agile_geek - I genuinely wish you luck with that; I have long-since believed that I am only going to fully transition to Clojure full-time by persuading a client (of which I currently have exactly none, as I am in a full-time job) to let me solve their problem(s) with Clojure.

@agile_geek - Either that or start my own business and build the tech on the Clj / Cljs stack 😉

@maleghast I'm hoping the first enables me to do the second.

*fingers crossed* for you @agile_geek 🙂

I have put in a proposal for some consultancy that could lead to this result but they're unlikely to be able to start it till October/November so I'm not sure I can be out of contract that long.

Oh man, that’s tough… Are you able to get on a plane and live cheap in the Greek Islands for 8 weeks or something?

(I have a friend out here who is considering going to Bali for 6 weeks to wait for a job to start)

I have 3 adults to support so not an option!

morning

moaning

Morning

I might be allergic to beer, makes me tired the next day

morning

@jonpither maybe just the alcohol?

maybe

moaning

@bigkahuna javaslang and pals look nice - thanks!

Which raises one of my problems with Java - it’s such a vast “community” (if you can call it that) that better ways of working often fall through the cracks. If something neat shows up in clojure land, I can hear about it fairly quickly. And I even get a reasonable bit of buzz about new things in JavaScript land. But Java projects like this get lost in the noise of “hey wow, look what Spring is doing now” 🙂

otfrom: somewhat late, but OSX has /etc/paths.d the contents of any files in there get added to your path

@glenjamin is that dynamic or when you load a new shell?

when you load a new shell

@korny as you say…. one if the things I like about the Clojure community is the fact that is quite small and you can know most things and keep up to date about what is happening.

Of course, the ruby community was like that once 🙂

And I remember a ranty talk from an old smalltalker, about how the Smalltalk community failed because it stayed too small and didn’t play nicely with business concerns...

I have this theory that the industry is not good at picking up things from academia (and academia not good at promoting its knowledge) and that is how we ended up with this disconnect between the two.

and that the industry is driven by practical limitations that the hardware had for long time

thomas: I've had some experience that academia is quite bad at picking things up from industry too and are very bad at industry collaboration (esp w/SMEs)

thomas: That's certainly true - but I think it's deeper than that... academia often has a lack of understanding around marketing; in particular the role of marketing around actually defining a product/solution/problem... I think a lot of this is because there's too big a disconnect between academia and industry. Obviously purely theoretical research can be worthwhile too - but often I get the sense that some academics are frustrated that their research isn't adopted by industry... and despite their claims I think it's often not because of promotion; it's because they don't understand the constraints around acceptable solutions. For the record I have a massive respect for a huge amount of research - and industry is certainly poor at picking that up too... but in those cases that's a business opportunity 🙂

universities also seem to incentivise papers more than commercialisation... and having been part of a university startup (many years back) I have experienced (second hand) how torturous IP negotiation can become

so I think that's another reason people choose not to pursue commercial angles

otfrom agreed. It's a real shame, as some of the most rewarding learning experiences of my life have come from working with academics in a a commercial setting. From my perspective there are dozens of hard commercial problems that I'd love to work with a gifted academic on.

was wondering if anyone has some reading on the life-cycle of a dev team. I.e. if a team doesn't refresh/rotate then it gets stale - some thoughts around this?

interesting perspective jonpither. I’ve experienced the opposite side dof it… team refreshing too quickly

yeah. I've recently seen a team arguably suffering from it's own success - people become entrenched & comfortable and it becomes difficult to get rotation happening, to discuss/approach large scale refactorings. If it ain't broke...

problem is that if you don't rotate, over time attrition will eat into a team and the codebase becomes old-fashioned, difficult to wrestle with

a software team is a bit like a sports team - it can't stand still, needs re-investment and new energy or else is starts to fail. in a sports team the process is a more rapid and more obvious...

interesting

those are my thoughts, but I'd welcome some reading / higher authority 🙂

of course, but the intuition makes sense

I've seen quite an extreme example recently, where only ~3 devs left understand a massive system, but they are so comfortable and still productive, and the project is considered to be very successful, just hard to make a case for change

Hmm - I have read some good books on teams, but don’t remember anything particular on this. I’ve definitely seen both extremes - teams that got stale, and teams that rotated too much...

Understanding massive systems is tricky - I’ve had projects where everything got touched regularly, so even new people got exposed to all parts; and projects where whole modules became legacy because no-one had to change them, so no-one did, and all the people who knew them well rotated off.

"change for changes sake" sounds like a bad thing, but actually it's wise just to continually rewrite / touch code. Few businesses would expect this recommendation tho... they probably like 'if it aint broke'

I think this is part of what microservices is aiming at: "don't refactor, throw away and rewrite b/c it is that small"

I’ve heard arguments both ways (on changing code) - I had a discussion with Adam Tornhill (the code-maat guy) who felt that commonly changing code showed risk areas and rarely changing code showed stabiliity; I tend to feel the opposite, commonly changing code is well understood, rarely changing code is quite possibly technical debt

korny: the academic literature points to areas that change a lot as having the highest bugs, but also suggests it changes a lot b/c it is a difficult thing (and many of the changes are bug fixes)

recency matters too, your bugs are mostly likely to be in the most recently changed thing

That’s what Adam says - my problems is that most of the academic literature i’ve dug into, was based on typical industry practices, i.e. untested bulk code written in slave pits

korny: well, that does cover most code. ;-)

yep 🙂

bit of a plug, but I wrote this after being inspired by software theory 'https://juxt.pro/blog/posts/after-the-honeymoon.html'

I like the idea that software is dead when there is no one with the underlying theory in their heads

other things to keep in mind: code maintenance effort scales with lines regardless of language (so choose a concise language), and the only thing proven to increase code quality is automated testing (can't remember if it was tdd or just testing)

@otfrom do you think that is true (less lines of code better) for write only languages like APL?

I suspect there might be an optimum

thomas: I don't think there are any good studies on that ;-)

mind you, all the studies on this say "our sample size is small, our sample group is not representative, our experiment was unnatural"

I think a big win for Clojure is that code-bases considered legacy are usually salvageable owing to their size

you can't resurrect a 1m LOC Java codebase, but you could probably cope with a ~25 LOC Clj one that is equivalent

I'd also say, the more tests, the more spec, more documentation, can go over a certain level that makes the resurrection more difficult, not less

@jonpither I assume you mean 25kloc clj code base?

yup

ah, this is what I was looking for http://neverworkintheory.org/

could it be that the clj code base would be easier to resurrect because the architecture would be easier to reverse engineer?

(speculating out loud here)

1m loc of Java code… and you’ll have a hard time figuring out where to start even

Dan North’s been talking about the idea of a “Software Half-life” recently

that has empirical software engineering and cs papers to say what has been shown to actually work

@thomas hopefully. I think you can be really crude and just say less LOC = more maintainable

@jonpither nice blog post

thx

I’ve seen million line Java codebases that could probably be replaced with 25 lines of clojure...

Ah - I had the concept of “Software half-life” in my head, couldn’t remember where from - I’m betting it’s Dan

just came across https://leanpub.com/softwarefaster

Yeah - I have that bookmarked, I think it’s been at 7% complete for a long time...

@jonpither probably true

he needs to write a book called “writing a book, faster” first

re:LOC - I’ve been playing with code quality visualisation tools, and it’s quite nice to just visualise the code with size of files shown by lines of code, and type of file by colour. The minute you see a giant blob of 20,000 lines of SQL pop up, you know you’ve found a problem.

or a db dump

@korny is that when you know you have to run?

@korny what's your viz tool of choice?

I was using D3 nested treemaps

The 20k lines of SQL was their migration script - auto-generated from a diffing tool that compared the “old” and “new” dev databases.

I’m actually rolling my own viz tooling - it’s stalled a bit right now. The goal was to combine simple tools like cloc, code-maat outputs, and other things into an interactive D3 visualisation

korny: have you seen the stuff from Karsten at http://thi.ng ?

Yeah, I looked at that a while back - haven’t looked lately. Interesting stuff there, though the org-mode based literate programming model, while clever, was a bit of a barrier to me

@jonpither: nice article... I once heard a myth (don't know if it's true) - that NASA has forgotten how they got to the moon, as basically everyone who worked on Apollo is either retired or dead... Even though they've doubtless written that knowledge down; the sheer quantity of it means nobody (or no team) knows how to do it anymore.... I don't doubt that they could put people back on the moon again; but they'd almost certainly be reinventing things (not least because of modern technology advances). I don't know the solution; other than perhaps to maintain a team of people practicing this stuff all the time. You need to keep these things alive in people and culture not just in books.

budgets that crash to nothing and then spike up again must really damage this sort of thing

I think it's likely that most systems spend most of their time with 0 devs tending to them. In DB we had 9000 systems in one dept, far more than the headcount. There are a few simple techniques that I believe help a system survive without constant tendering. Keeping devs around tinkering is probably a) wasteful and b) mundane for the devs. A lot of my http advocacy is centered around the concept of longevity whereas most people focus on other things, like scaleability and 'agility'

But I do believe that as the industry matures, it will 'slow down'. There is plenty of evidence for that outside our bubble of excitement called clojure. So 'longevity' will gain importance as the fraction of a system's life where it is actively developed decreases.

+1 malcolmsparks - agree tinkering and doing mundane things isn't a great idea... so long as there are practitioners and a culture you can buy into it as and when you need to. Naur's theory building stuff + context from experienced practitioners seems like one antidote

I feel with the library driven development of the jvm ecosystem and all the things over the years in lisp and unix that we've already become programmer archaeologists

and that we should be practicing those skills too, whereas they are generally looked down upon atm

Haha but no thanks for the hipster side of development

I’ve done like 7-8 years of python and feel the same, on the old side

I kinda miss program archeology

last few years i’ve ended up on greenfield stuff

@glenjamin wanna swap?

😉

Greenfield stuff that mostly hasn’t shipped, despite my best efforts

although this current one looks like it’ll ship into private beta soonish

yes… that can be a problem on greenfield I guess… the first project I worked on took 4 years before it shipped.

I did a couple of “tech assessments” - more like forensic program archeology - looking into the mass graves to work out who should be tried for crimes against Knuth. Lots of fun.

eugh, I have a thing about Knuth

ever since I saw an interview with him where he talked about TeX. And said how great it was that it was done. And had no tests, and never changed anymore

he wrote all the code for it… then went on a 2 week trip… and when he came back he compiled it for the first time… and started fixing any typos.

there is no way I can do that.

@glenjamin: I don't understand your complaint about his assertions

As I understand it, TeX is a mess, and plenty of people do want to change/improve/enhance/develop it. But they can’t - because it has no tests.

Yeah - better not look too closely at some of the old-school coding heroes sometimes 🙂 At least he isn’t an axe-murderer

I'm still not sure I understand. Are tests a precursor to development. Are they required entirely up-front?

Tests are required to make changes to complex programs with confidence

Especially if you aren’t the original author of those programs

He wrote some great software, but decided he didn't need tests because he understood it well when he wrote it. Now it’s calcified

I’m so glad none of my early projects have the longevity of TeX. I can’t imagine going back to the pre-testing world.

Wonder what tests would look like for Tex output, pretty tricky I imagine

Could TeX be tested now by visual regression tests?

Thinking about it now, it wasn’t even his decision to not write any tests that annoyed me, it was that he was still proud of it in retrospect

Yep, annoying

Maybe quad will be a good replacement one day. no tests yet though https://github.com/mbutterick/quad

i have no idea how you even approach testing typesetting

I guess similar to http://acid3.acidtests.org/

@glenjamin: printing often involves stochastic screening these days, which might throw a spanner in the works of that type of test...

from Wikipedia: In particular, since Knuth highly values the reproducibility of the output of all versions of TeX, any changed version must not be called TeX, or anything confusingly similar. To enforce this rule, any implementation of the system must pass a test suite called the TRIP test[44]

<ftp://tug.ctan.org/pub/tex-archive/systems/knuth/dist/tex/trip.tex>

more like a functional test, not a unit test

% This is a diabolical test file for TeX82. Watch your step.

oh, that’s interesting (and good)

that file us surprisingly small acual