Hacker News Reader

Comment by dustingetz | Hacker News Reader

1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your problem is that is holding you back – drinking, eating, whatever – fix it today 7) Learn Clojure

View on HN

I like your list, but I’d suggest:

8) learn a statically typed language with a good type system

Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase

Agreed. If you grok a best-of-breed dynamic language (Clojure included), and also a best-of-breed statically typed language, you're in rarefied company. And I would add "Learn C or assembly" to grok mechanical sympathy.

What you say sounds interesting but could you give an example of "think in contracts" compared to and example of "knowing the runtime state in your head".

Personally I have never really seen the advantage of staticaly typed languages over say Python, but I do rely on the strict typing supplied by a database instead.

What I mean is that static typing makes interface boundaries (modules, function parameters and return types, data structures) explicit, and those boundaries are enforced automatically. Those boundaries become a contract, where a provided interface and its call sites must agree on in order to be run. This is like a million little unit tests you get almost for free (obviously you have to write the types, but they're usually declarative and very expressive).

But it also serves as documentation of how any part of your program's state is structured at any point. To the degree a type system is sound, and to the degree your types are appropriately detailed, you can be assured the documentation is correct and up to date as long as the program compiles. This allows you to eliminate the question of "what does this data look like?" when you're reading code, and focus more on things like whether the logic is implemented correctly.

Since you mention it, I'll add that Python does have (optional, gradual) static typing, and a lot of work has gone into the type system in recent versions. It's worth spending a little time adding some static types in a project and seeing some of these benefits. When I last worked in Python, you had to run `mypy` to actually fail on static type errors, I don't know if this is still the case. But you could also use an IDE (like PyCharm, surely there are others) which will at least surface static type errors while you work.

I have been using Python type hinting recently, but I don't find it such a big game changer. Maybe I am just used to writing code without it and it will become clearer if I use it more. Like I say I don't like having an untyped database, and the benefits there aren't things that are obvious straight away.

When I last worked in Python, I also didn't get much benefit, but I wasn't using either mypy or an IDE that warns on type errors. While obviously a different language, it wasn't until I worked with TypeScript in VSCode that I really came to appreciate static typing. And after a few years, I don't think I could go back to working without it.

What is your reasoning behind the recommendation to learn Clojure? I am generally unfamiliar with it but saw it was a general purpose language. What makes it so valuable to be included in your list?

I'd think anything in the LISP family would qualify

You must understand the point I am missing. Why learn a language in the LISP family as a young developer? Does it somehow improve you overall?

Once you have grokked Lisp, everything else feels weak by comparison, as I understand it.

Mostly the appeal is how easy it is to extend the syntax (because there is barely any syntax at all).

Disclaimer: I have written a good hunk of Emacs Lisp and also written Scheme professionally, but I have yet to grok macros.

Never used Lisp, but this sounds like a case of offering you loads of cool stuff when writing new code, which in turn will make debugging the code an absolute nightmare. This is based on my experience with mixed metaphor languages like Python. You can do some clever stuff like generating functions dynamically and passing them around, but when you need to debug these bits of code they can be a nightmare. Does Lisp improve on this in any way?

I believe that macros can increase the complexity of debugging.

However, I believe they're much more debuggable than dynamically-generated functions in most languages. There's another layer of translation from your baseline code, but due to the nature of macros, you can usually just step right into them and see the expanded, generated macro code, if my rusty memories of debugging elisp are correct.

Here's one person reading about Common Lisp's debugging infrastructure, FWIW.

for me it's hard to separate it from reading SICP, which as a self taught developer, I feel brought me to a different level of understanding concepts like immutability, the shortcomings of oop, streams, eval apply and so on.

I’ll second this. You don’t even have to go all in and spend a year programming it. Just dipping your toe into SICP/Lisp every once in a while is enough to shock you into realizing that there’s a much broader scope of possibilities in programming that has not been effectively exposed to you or the masses.

SICP really gives you a “full-stack” appreciation for software (from applications down to compilers and interpreters). It’s horizon-expanding.

Clojure is indeed mind-expanding. Unfortunately its most compelling ideas don't translate to non-LISPs, so I must sadly disagree with the "learn Clojure" suggestion. It's wild fun, but it's hard to apply the ideas to DayJob.

An example: threading macros. In a language like Haskell, partial application is optimized for left-to-right. `f a` substitutes the first argument; other orders are more awkward. Functions like `map` deliberately place the "most known" arguments first to aid in partial application. If they guess wrong the code gets twisty.

But Clojure's threading macros compose functions, while just letting you say where you want the argument to go:

  (as-> [:foo :bar] v
     (map name v)
     (first v)
     (.substring v 1))

Here `as->` creates `v` as a meta-variable which means "the result of the last function". The code seamlessly mixes the declarative and imperative. It's like nothing else.

Sadly no DayJob language has features like this, and Clojure has other weaknesses which become apparent rapidly. Clojure learning will leave you yearning.

> Clojure is indeed mind-expanding. Unfortunately its most compelling ideas don't translate to non-LISPs, so I must sadly disagree with the "learn Clojure" suggestion. It's wild fun, but it's hard to apply the ideas to DayJob.

I must say, having learned Clojure (and ClojureScript) and used it in production in my day job (we even still have one ClojureScript project in production), I strongly disagree. I would probably not choose to use it again, mostly because I've come to prefer static typing, but quite a lot of what I learned from learning it (and learning its idioms) has greatly improved my work in other languages.

In particular, Clojure's approach to state is something you can (mostly) apply in most mainstream languages. Handling most runtime state as immutable values, with clear and explicit use of mutable state for the cases where it's either necessary or makes the code easier to understand/more maintainable, is a huge boon for developers working in imperative languages.

In my current job, I've seen the quality of projects improve drastically as I've lead by example with that approach, and as I've asked for changes like it in code review. I've seen the volume and severity of bugs decrease, developer productivity improve, and morale trend upward.

> Clojure has other weaknesses which become apparent rapidly.

Clojure has lots of strengths which also become apparent the more you works with it: async, thread-first, thread-last, transducers, core.logic, (partial f a), flexible composition, expressive-ness unrivaled in Dayjob language, hundreds of functions that just work on whatever data you're dealing with, tapping into java "dayjob" libraries without having to deal in actual java. The list goes on.

I've re-written a few applications & libraries from javascript (and other dayjob languages) -> clojure(script). In every case, the lines of code drastically dropped, the functionality expanded, the readability improved, and performance was always on par or better. It's not a silver bullet for everything, but its strengths far outweigh its weaknesses. Like any good mind-expanding drug/language.

> Clojure learning will leave you yearning.

It has been my experience with learning clojure that with each new problem, it has left me yearning ... to learn the more elegant, composable, flexible, robust solution ... in clojure! YMMV.

>3) HN is 3 years ahead of mainstream, but 10 years behind the edge

I think you're using a weird definition of 'edge' here to mean "things that nobody else knows about" rather than the cutting edge of the industry/academia.

Academic publications occasionally float across the front page here that have only been public for a few days. That's pretty much the 'edge' of industry-wide knowledge.

If you want to include things that aren't public, that's super vague and sort of pointless.

> Whatever your problem is that is holding you back – drinking, eating, whatever – fix it today

D'oh! Why didn't I think of that?

Can you expand on 5? Why shouldn't you optimize for money as soon as possible?

Probably because it's easier to quickly grow a free product/platform and then add monetization on top, than have users pay for access or endure a worse ad-cramped experience.

what / where is "the edge", in your mind?

it’s a git repo sitting unused on some 20-something’s laptop, because anybody rich enough to market it doesn’t know enough to recognize it

Can you point to some worthy examples of this as proofs of existence? And I mean something truly novel, and not simply a different way to do something we already can do.

https://github.com/steve-chavez?tab=overview&from=2016-10-01...

https://github.com/begriffs?tab=overview&from=2016-10-01&to=...

How many projects are there to automatically API-ify a database with auth boilerplate today? At least a few well funded ones, one recently funded by YC even.

They came up with it in 2015? 2016? and still have a thriving project going with it. Looks like less than 10 people have more than 10 commits in its history:

https://github.com/PostgREST/postgrest/graphs/contributors

Having followed the PostgREST project for years, it’s been wild to see the recent explosion of similar sorts of projects (as you describe); I’d very much believed this was a “solved problem”.

CouchDB is a database from 2005 that can _only_ be accessed via a REST api.

And Solr in 2004, but a json store returning json is not really the same as building a highly performant SQL client that works over http with support for operations on ~45 to 50 data types.

>How many projects are there to automatically API-ify a database with auth boilerplate today?

That's a really vague statement but you described phpmyadmin, django, wordpress with a plugin, etc. Most successful CRM companies essentially have some framework doing this underneath as well.

I’ve only seen a couple of repos like this, but I’ve seen enough to agree that this is totally the right answer.

To people who doubt it, keep in mind that 10 years is a very very long time. Rust is not yet 10, Go is just barely 10. React is 7 and jQuery is 13. Cloudflare is 10, Stripe is 10, Hashicorp is 8 and Docker is 7.

Reply on news.ycombinator.com