Hacker News Reader

Comment by bdcravens | Hacker News Reader

Understand business needs. Be able to communicate. Be upstack: infrastructure, DNS, SSL, etc. Go deep on security: many concerns cut across many languages, but if you're a language/framework of the week developer, you're too busy learning the same thing over and over to have that depth, which businesses desperately need.

(I'm 40 and my current role is with a small company where I implement solutions rather than have a title)

View on HN

> Go deep on security

Bingo.

Security is one of the few cross-discipline, cross-domain specialities where it is possible to be a reasonably good domain expert and still have a good coverage across other domains. The fundamentals don't change. (And I say this as someone who's been immersed in the field for 25 years, so of course I'm biased.)

There are few other domains that can offer the same level of constant demand.

The beauty - and the depressing aspect - of security is that maybe 10% of security is about software. The remaining 90% is all about what is between people's earlobes. To become good at security, you'll need to learn how to explain extremely difficult and often subtle concepts. And you'll have to do that for both technical and non-technical crowd. That's a fantastic and continuous trial by fire. It's also lots of fun!

Bonus: because everything is a tradeoff, you really can't avoid the engineering approach. Teaching the concepts and reasons for tradeoffs to less senior developers will be part of the job specification. Fun.

> language/framework of the week

To quote something I have often stated in our interviews - there are only four programming language families. Everything else is syntax.

Can I ask which are those families?

Of course.

1: Imperative - C, Fortran, Pascal, ...

2: Object-oriented - C++, Java, Python, Ruby, (maybe Delphi's Object-Pascal), ...

3: Functional - OCaml, Erlang, Haskell, F#, ...

4: Declarative - Makefiles, QML, SQL, ....

To be perfectly honest, I don't know which bucket I should use for Prolog. It's supposedly logical, declarative and functional at the same time. I've never managed to understand it, despite trying.

And for the record: perl in basic form is imperative. With the introduction of "bless" keyword it crosses over to object-oriented domain but following the syntax is not necessarily straightforward. [I've spent a non-insignificant number of days auditing OO-perl. It's not a pleasant experience.]

Those are more dimensions than buckets, and not very orthogonal ones at that. In particular there is strong overlap between declarative and functional language features (you could argue functional is just a special case), and less strong overlap between imperative and OO languages, and OO and functional. OCaml fits pretty comfortably in all four of those categories, when you want it to.

If I wanted to jam languages into 4 categories, it would probably be the Algol, Lisp, and ML families, plus All Those Other Languages. :)

I'm curious, what makes the ML families different than Algol?

The ML family tend to come from a research background, have a more rigorous approach to typing, solid type inference, and very differently flavored syntax. MLs are functional (first-class functions, expression-orientation), whereas the Algol family in the shape of C, Java etc are mostly imperative. They tend to have nice pattern matching facilities. There's more, but that's a lot of it. A lot of these features have been transplanted into languages that are basically on the Algol tree, so it's often a bit fuzzy these days.

I reckon imperative and OO are almost identical; if you don't have objects, you use function pointers or discriminated unions instead and end up with something very similar. OO is a design pattern that often has language support. And I could make a similar argument that functional is mostly just a style of coding, where some more restrictive rules are followed - but it also depends on a few specific language features, e.g. garbage collection and possibly tail calls. You can get by without pattern matching and first class functions, but they make life much more pleasant.

Declarative vs imperative is more interesting: what vs how, building descriptions of problems rather than chains of calculations or lists of steps. I don't think functional style is strongly related to declarative, except in the very low level sense that a functional program doesn't necessarily have a sequential evaluation semantics. But that's increasingly true of seemingly imperative languages also.

I've had teachers separate languages (or styles, or paradigm) in 3 categories:

* Imperative languages describe how to perform the solution.

* Functional languages describe the solution.

* Logic languages describe the problem.

I'm not sure I actually agree with this categorisation, though.

Reply on news.ycombinator.com