cursork

Absolutely this. When facing a tough problem it’s a great tactic to write out what you’re trying to solve and how you plan to solve it in prose-style English.

I’ve done it often without ever sharing my writings with anyone at all, and always felt that the code turned out relatively good as a result.

I’d also add that a very prototype that you throw away also helps line up your thoughts.

The key is having something reasonably concrete in front of you that forces you to think of the invariants, compromises, etc in the system. Before making all those decisions concrete by writing loads of code

I agree with this to a large extent. A new codebase in the latest Java/whatever can be OK. But most of the time I feel like it's dealing with the same bad code, with just a smattering of nice syntax on top.

I started learning Perl in 2007; after it was no longer popular, but also around the time that the principles/practices that became 'Modern Perl' were becoming popular in the community.

I think there is a difference between the two though. Java was always a language which required a lot of ceremony and typing to get anything done at all. Perl was always focused on expressivity. Modern Perl was a case of learning from past mistakes and consciously avoiding some of the more egregious code the language easily afforded. Modern Java is more a case of Java playing catch-up to the more expressive languages out there.

One is applying constraints on your coding style, the other is trying to lift constraints. Both are trying to reach some middle point.

But! I agree that no company writes purely 'Modern Perl' - you will have to deal with some terrifying code at some point.

So. I agree with the concept of the 'Modern X' fallacy, but I would say that dealing with non-modern code is pretty normal, and people who are OK putting up with the pre-modern code may be some of your best employees. I suffer from rewrite-it-all syndrome myself sometimes, but it's something I try to avoid. Code that frustrates me, isn't necessarily bad.

(If it helps contextually, I'm - at heart - a Clojure programmer.)

See also Liberator for Clojure

Seems to be a typo?

    $ perl6 -e 'say "नि".codes'
    2

Presumably a riff on "Lisp has no syntax"

Also Perl: 5.20 is current stable, 5.21 is unstable but will eventually lead to 5.22.

http://perldoc.perl.org/perlfaq1.html#How-often-are-new-vers...

Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview. It's a bad signal.

Maybe it's just my experience, but the more 'forgiving' style of interview has tended to result in a better work environment.

There are some situations where you do want to hire someone who 'knows it all' already. In which case, fire away with these challenges. But they're not needed for the 99% case.

Not a direct response, but expanding my thoughts slightly:

1. I know many highly able programmers who wouldn't know how to respond given so many options. These 'tricky' questions just aren't good for some personality types.

2. Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level. I'd hate being pigeon-holed just because I happen to know one thing.

3. There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.

That's only superficially the same. There's questions and there's "let's work through this" questions. The latter are awesome when explicitly stated as such and can be (should be?) as hard as you want to make them - I find I learn from them whatever happens.

Love it! One of my favourite bad interview questions. I got asked this in an interview ~5 years ago. My response was to look shocked... Pause. Then ask: "What do you mean? What detail do you need? DNS? SYN / ACK? HTTP?"

At the point I started talking about syn/acks they just cut me off and moved on to the next question.

Same company (different person) started the phone screen with 'oh so your CV says you know linux, what's the difference between a hard link and a soft link' and was shocked when I knew the answer, declaring the rest of the phone interview pretty pointless - he'd obviously had a bad morning and started with his hardest question.

I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.

Saw the presentation for this at ClojureX in London. I'm definitely interested to have a look

https://skillsmatter.com/skillscasts/5738-keynote-by-kyle-ki...

Oh wow. The attitude on display is really not good.

That's a great book. I've just started reading I Am A Strange Loop by Hofstadter and it's promising.

Also by Hofstadter: Le Ton beau de Marot was a good read.

GEB is the big one, but if you like his style - probably worth checking out some of the others. Best to get print books for this particular author though.

Re. "Continuously Deliver them to the Docker Registry". Is this focussed on open projects going to the public registry? Or will you provide a private one / integrate with services like quay.io, etc.?

EDIT: Love CircleCI by the way.

Yeah. Bad use of 'patent' maybe. Just interesting that the same arguments are provably going around and around.

Possibly more interesting... start the video from the beginning and they're talking about software patents. The same points were being brought up then as now.

But yes. Good video! Cheers!

It's Wiki is pretty killer.

That may not sound like much, but it's pretty awesome. I use it as a reference on a few things even when dealing with other Linux distros.

e.g. The page on SSH basically starts with how to restrict users who can log in and disabling root. https://wiki.archlinux.org/index.php/Secure_Shell

Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.

The consensus in the community right now is to not get carried away with macros and DSLs. Even if your library provides a DSL, it should be based on a functional API that is mostly usable without macros.

Yup. But what people say and what people do is often not the same thing :).

Thanks for this; pretty much the response I was expecting but very well said.

My opinion is that functions that take quoted code do actually do the 99% job of macros pretty well. I also think creating completely new syntactic forms is fantastic for a solo project; but not so great when working in a team. So I'm left thinking what difference does it actually make. My general feeling is that I tend to write macros in Clojure just to deal with someone else's macros; i.e. macros 'layer' whereas functions compose.*

Incidentally, I've been curious about but never looked at Erlang's parse transforms because they have - in my mind at least - a big 'here be dragons' sign above them. Enough articles have warned me off to make me nervous. Would love to know more though.

* No idea if that makes sense to people. Hope so.

Kinda fair - I meant "homoiconic" in the loose sense of having macros that can manipulate expressions as data and which has mechanisms such as quote/unquote to do so.

That's what many people see as the reason for homoiconicity after all. I put it in quotes, but maybe I should have said something about how languages can support sophisticated Lisp-like meta-programming without being a Lisp at all.

Nonetheless, as I'm still learning (aren't we all?), I would love to hear what a truly homoiconic language has above something like Elixir with its quote, unquote and unquote_splicing. By truly homoiconic I mean that AST is equivalent to the written form.

EDIT: I now realise you're not only rvirding, but that you wrote Lisp Flavoured Erlang https://github.com/rvirding/lfe so therefore (I hope) are in an even better position to educate!

100% agreed. I've been looking at Elixir occasionally for a year or so... It's getting better and better. It certainly takes a lot from Clojure, but with a real Erlang / OTP twist. (It also recognises that "homoiconicity" doesn't always mean lisp). Elixir's Design Goals are stated here for those who've missed them: http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/

Literally came here to post that!

The comment for send-line-to-tmux... I've felt that pain before.

Really hope this doesn't sound like belabouring the point but...

tpope is one of only a few driving forces over on the Vim side of Clojure

tpope is indeed one of the few, but I'd hate for people to dismiss https://github.com/guns for his work on vim-clojure-static, vim-clojure-highlight, etc. Both have done a great job on those projects, but also with engaging with the community.

And let's not forget Meikel Brandmeyer, met him once, lovely guy. But also spent a lot of time delivering VimClojure back in the day. (I'm glad I don't have to suffer nailgun any more!)

I think there's plenty enough willing people (I'm one - I've contributed 1 or 2 line snippets here and there). But the environment is actually pretty damn nice already. No complaints.

All analogies break down. Of course.

How about (staying with the building analogies because I'm in a building right now and looking around trying to think of analogies...) the electrician who has wired your flat? You don't think anything of the lights coming on when you flick a switch. Live in a place that's got slightly mediocre wiring, you don't really notice generally, But once in a while it bugs you that the light just blows sometimes. For no reason.

Of course, there's no error messages for a light failing. It doesn't tell us why it failed.

In truth I think our discipline is a unique discipline. Just like everyone else thinks theirs is (tell a plumber they're basically equivalent to a gas engineer or vice versa - but we 'normals' treat them that way). But we tend to concentrate on our new, unique-ish-ness. Our field is young, it has a long way to go. But essentially I don't see why programming needs to be, or should ever be, elevated to a particularly special status.

Point I didn't bother making explicit in my first post: Great music and art both have an effect on people who are not versed in music and art. Great programming only has an effect on fellow programmers.

EDIT

I think my basic point is that we should see our jobs as those where we get our work done. And we do the best job that we possibly can.

That's it. Not over-burdening ourselves for 'just one more push' (I'm currently failing somewhat with this in my current contract - do what I say; not what I do..). We as a group need to realise that like other people, we need to go home sometimes and relax too... That's the most beneficial thing. Not believing that our job is somehow exempt from the work/play balance

For this comment I'll try to stick to one specific thing. I'll focus on the mechanic analogy, but I do think the premise of the article is flawed. I have some thoughts about burnout in programmers etc. but they aren't well enough formed for a 1am UK time post...

I actually think the analogy of car mechanic is really appropriate. Many people (myself included) could not fix even the most trivial of problems. I have fixed some very very trivial problems by poking around / research, but as a general rule the car has just gone into the garage, and someone else has fixed it for me.

I've also once had a car in the garage for over a week. I briefly mentioned the problem, over the phone, to my non-mechanical grandmother, only to have her diagnose exactly the issue at hand. Simply: She has had the same thing happen to one of her cars. Those mechanics hadn't seen it. So she was correct. But that anecdote doesn't really mean anything. It was just one of those things. Experts can't know everything and those car mechanics will always know more than my gran about cars!

'So at the end of several days' worth of programming, and problem-solving, and forward-thinking, all a programmer might get is a "thanks, now here's the next thing I need you to do."' - yes! That's exactly how mechanics (amongst others) are treated! Who pays a mechanic and says "amazing job" when they don't understand the original problem? It's meaningless faint praise to say good job for something you don't have an inkling of the difficulty of.

The whole article sounds like the author wants programming to be treated as art. I tend to agree that it takes great skill and dedicated learning to become a good programmer. But I don't think that is what defines art. It takes skill and dedication to become a good carpenter, a good brick-layer, a good joiner... But no one gives these guys a round of applause when they do something subtly brilliant. It's only others in their craft that go "hey, that's really pretty nice, well done".

* Sorry. Building references just came to mind. People don't notice when they do a good job, but oh boy do they notice when a not-quite-good-enough job is done!

I'm a big proponent of everything-behind-http because of the way it introduces a common language for integrating disparate services.

However! as someone who has had to debug some particularly gnarly email issues in the past I really do quite like the ability to telnet into an IMAP server to dig around. I also have an appreciation of some of the more horrific things that can go wrong...

So my point is that I'm not sure I agree with "generally much easier to work with than IMAP" - there's two types of "working with". One is building a new client/server from scratch - I'd agree this might be easier, but not something that is done that often. The other is being able to quickly investigate issues with hand-crafted queries, and unfortunately I'd say a simple plain text question-answer interface is better - and here IMAP wins.

Maybe I'm just getting old - it's probably true that almost everyone is happier with HTTP than "telnet-able" protocols (SMTP, IMAP, Redis, etc.) nowadays.

Explicit declaration of the scope of a variable at initialization leads to unintended global namespace pollution when omitting the declaration is legal and causes the variable to be placed in the global scope

Ah, but it's not legal with 'use strict;' (which everyone uses)

That's because programmers who care about good syntax in their languages don't use Perl.

And Lisp has too many parentheses. I clearly just like my code to be illegible.

Not completely seriously.. This is why some of us prefer Perl ;)

    my $a = 1;
    
    my $contrived = sub {
        my $a = 2; # new lexical variable $a
        $a = 3; # if the my above wasn't there, outer $a would be 3
        ...
    }

    say $a; # 1

I've never heard anyone ever complain about perl's lexical 'my'.. It even catches - with a warning - multiple my declarations that will clobber each other. You don't see that in other languages that often.

Perl is actually very good with Unicode. Note that a character is "The smallest component of written language that has semantic value" according to the Unicode glossary - I'd say Perl respects that meaning. As noted in the docs, graphemes can be handled with \X in regular expressions (although admittedly that's not pretty):

    my $length = 0; $length++ while $dec =~ /\X/g;

http://www.unicode.org/glossary/

To ameliorate my point; I use LYAH as a reference piece a lot. It's well written and is a really takes time over many subjects. I mostly wanted to make (badly!) a point that there are resources out there that will push experienced and non-experienced alike. And they don't need to be in the language you're looking to learn right now.

Either way - I hope to give Write Yourself a Scheme... a go sometime soon. Looks good.

LYAH is a chore. I got nowhere with it - it is tedious. After a cursory glance a few of us at my company are working through The Little MLer in Haskell instead. It seems to really be focussing on types and I think those kind of core concepts are important to grasp at the early stages.

More importantly, the Little Schemer and The Little MLer are aimed at non-programmers... yet programmers struggle with them. We should question why that is.