joncampbelldev

Perhaps they meant it as a good example of the type of component to build systems out of, simple input->output. Unsure though.

It is usually encouraged on HN to argue with / respond to the points made by the person you in discussion with, not the vocal minority/majority out in the world who hold a different view.

Otherwise you get two people talking past each other. The fact that there are people who are fans of gun control AND express themselves immaturely with vapid politicised statements appealing to emotion doesn't excuse the almost trollish characteristic of the "do you think women should be defenseless against rapists" above.

And yet 99% of code written in Java, Ruby, <Generic OOP language here> is based on mutable objects.

Its not about what is possible, we're all familiar with the turing completeness of everything. It's about what is: the default + easy + encouraged in the ecosystem.

I believe this is usually called the "Please think of the children" argument (or women in this case).

I imagine the person you are replying to is not a closet rape supporter, but they likely think that allowing every adult member of a population to arm themselves is not the ideal solution. I imagine you disagree with that view, but the way you have expressed yourself is the start of an emotional flame-war, not a discussion.

Except if you're using immutable data, pure functions and explicit state there's a lot less room for OO which (as presented by ruby, java etc) involves mutable data accessed/changed via methods that conceal their state.

In the grandparent comment's link (showing clojure data in haskell): I'm pretty sure that is not how people code in Haskell, its not how the libraries are usually designed etc etc. Using only data is definitely possible in Haskell, but it's not encouraged by default, the core abstractions are used for concretions of information.

In the same way you can do immutable and functional stuff in java, it's not going to mesh with the rest of the ecosystem or language around you.

Forgive me, but your comment seems a little disingenuous with the way it generalises the static community (every static language??) vs the clojure community.

Many of the comments on this page show why Rich gave the keynote. Because the same advantages of type checking are put forward as a reason to not use clojure over and over. They're not wrong, static typing has advantages, but I see little acceptance of any tradeoffs (or even acceptance that such tradeoffs exist: concretion of information, coupling of distant components by shared types etc etc etc I'm just paraphrasing the keynote).

He was highlighting the value proposition and tradeoffs of: being data-oriented, being dynamic and clojure.spec niceness. He felt the need to do this because he clearly felt that some people who were wavering about clojure were unsure why it was dynamic: "can't we have all this great stuff AND static types". He wanted to say "yes quite possibly you could, BUT here's the reasons why I didn't add types".

And some believe that the added value is not worth the trade off in mental overhead and ceremony. We are surely both aware of the various, numerous and flame-war arguments for static vs dynamic typing. (For my side I can only recommend Rich Hickey's talk "Effective Programs", he says it better than me)

My main point was that dynamic typing should be judged by it's best implementations, not by JavaScript. For example, I would not judge static typing by Java or C++.

The main issue is that Haskell is not a data-oriented language by default, this means its no fun to push it to be that. For example, I also have to use java in my job, I use persistent (functional) data structures all the time, but Java is not built for it, its not fun. (Although definitely more fun that using Java's mutable structures, ewww)

Also I personally find that to be too much overhead and ceremony in return for some type checking at compile type, as opposed to spec checking at runtime.

Again, I would refer you to the Rich Hickey talks, I'm not very eloquent on this. I think its about the manual overhead that constructing your hierarchy of types, plus the cognitive overhead of doing all the fancy things in your brackets.

I'm familiar with the advantages of type systems (my progression was Java -> Haskell -> Idris) but I found my personal productivity (even in larger systems built in a team) was best in clojure. I didn't feel that the guarantees given to me by the type system were worth the mental overhead, a lot of people feel differently (you amongst them I'm guessing :p)

As a closing point, if I were to ever build something that truly had to be Robust in a "someone will die if this goes even slightly wrong" way, I would reach straight for Idris and probably something like TLA+. However most of my development revolves around larger distributed systems communicating over wires, still resilient but in a different way. Mainly I use clojure.spec in core business logic and at the edges of my programs, for generative testing and ensuring that the data flowing through the system is sensible.

One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list).

This is what allows reuse.

- The vast core library of functions that manipulate those data structures can be used for everything in your program, cos it's all data.

- Most clojure libraries take and/or return data, reducing the need for clumsy adaptors, or even worse not being able to get at the data you need cos the library writer was really enthusiastic about encapsulation of everything they thought was of no use to consumers.

- You don't have a person class, you have a map with a first name and last name. Now the function that turns first + last name into full name can be reused for any other map with the same keys. (A rather spurious example, but a real one would take a large codebase and an essay to describe)

I can only recommend watching some of Rich Hickey's talks, particularly these ones, they're not entirely about types, but they express the above ideas much better than I can:

- Simple made easy https://www.infoq.com/presentations/Simple-Made-Easy

- Effective programs https://www.youtube.com/watch?v=2V1FtfBDsLU

- Are we there yet? (this one is more about OOP, but unless you're using something like haskell, idris etc its relevant for your type system of choice) https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...

I think the debate may be leaning towards dynamic.

- The aforementioned keynote highlighting the various reasons Rich chose to make it dynamic.

- CircleCI (one of the major users and propronents of core.typed) dropping it.

- The introduction of spec as an alternative for some of the reasons people use type systems (its certainly not a drop in replacement and doesn't intend to be).

- Spec allowing different kinds of verification not possible with a type system on its own.

Javascript and Python are very popular dynamic languages, this doesn't make them good dynamic languages.

In particular OOP is very much helped by static types.

Clojure would a better example of a dynamic language that would not be improved by adding static typing. Namespaces, functions and immutable data (as well as pervasive use of data instead of wrapping it in classes) lessens the downsides I bump into continuously when doing javascript development.

I'm saying this as a massive clojure fanboy: java.util.concurrent is an amazing set of concurrency utilities and is the building block for many of clojure's concurrency features. It's definitely worth knowing when writing performant java AND clojure (you can wrap the little bit you need so you don't have to scatter java interop all over your codebase). Sometimes a (swap! atom fn) doesn't cut it.

run! and doseq are for IO on each element of a sequence. Functions like mapv are intended for data transformation, not side-effects. This is why run! and doseq return nil

For the nested object traversal, is there a reason this uses string based paths instead of array based? Dynamic path building via string concatenation feels messy.

Seems like there may be a performance hit too with all the string operations inside 'utils/getNestedObject'. Probably not an issue for messing around in small amounts of data, but using this to manipulate a big server response could run into issues.

2^10 = 1024

2^20 = 1048576

I'm sorry, but I'm a little confused by your comment about default cases in reply to mine about syntax extensions being in the hands of language designers vs everyone.

I am also a little unsure what you mean by not worrying about default. Even polymorphism has to deal with this, if you call a polymorphic method on an object that doesn't implement that interface you'll get at best a compile problem, at worst a cast exception. This is why some languages provide support for a "default" or "method not implemented" hook in polymorphism.

If you are arguing that polymorphism is a better way to build systems than switch/case statements then no argument here. Open constructs like polymorphism are far better for growing and evolving large systems over time.

That doesn't mean we should exclude a nice way to say "i've got a variable that i want to translate to some other value in a few different ways".

My point was only that it just seems so silly to me that everyone is discussing whether this syntax is "best" or how it "doesn't do X, Y or Z", because I remember doing that too before Rich Hickey (angelic choir noises) showed me that actually you don't have to put up with that shit. Just use a language that puts syntax extension in the hands of it's community and let them figure it out without burdening the core language with a thousand little tradeoffs for the 90% use case.

I must have gone full lisp weenie, because I find it ridiculous when remembering the days of being a happy java dev, waiting years for someone to include a syntactic change in the spec, all whilst crossing my fingers that they will include my use case.

Clojure macros have spoiled me with cond, condp and case plus whatever else I or the community come up with. And my half thought out changes are nicely isolated to a single project or library instead of baked into the language for eternity.

On a page crammed full of images its alright, they're going to be slowing down the loading of everything.

If it were a plain text document and it was only JS loading and parsing that slowed it down then it would indeed be embarrassing.

My response is to the person asserting that JS is the reason this page is slow. I'm not making a statement that this is the greatest and fastest loading page on earth.

Nope, javascript is less than 1/4 of this page, time for the "above the fold" render for me (on standard laptop + broadband) is under 0.5 seconds.

Please examine other possible causes for a 30 second page load, unless you're running on an 1st gen raspberry pi, 56k modem and a browser with a showstoppingly bad js engine.

EDIT, using chrome's dev tools I tried loading with the "slow 3g" preset, rendering of useful textual + hyperlink content took under 10 seconds, images slowly came in after that over a longer period.

Technically correct, but speaking for myself: I was interested to read this job description even though I have no intent of applying.

Although I realise that deciding where you draw the line for "interesting job descriptions" is very blurry.

Also on the subject of clojure's data structures, they are all immutable by default (with structural sharing so changes are efficient, not just defensive copys). This greatly assists in writing functional, multi-threaded code.

For original asker, see here for more details: https://clojure.org/reference/data_structures

What you describe is exactly the same as what jdavis703 said, not the opposite.

I believe the quote you're referencing about monads is "this is meant to lull you into believing everything I say is true, because I can't use monads for that" (referring to an animation of a stick figure juggling)

Google tends to be better than most in-site search, especially github.

"guacamole docker" returns a whole page of helpful resources (github, dockerhub etc)

Namespaced keywords can really help with refactoring your domain model.

Usually I use normal keywords for throwaway or glue code, but anything important (my actual domain entities) will be namespaced, allowing (relatively) pain free refactoring.

Cursive has a few good refactoring tools/shortcuts, but I would also like to see extract/inline/move for functions.

The article mentions the difference between operational and product analytics, his complaints of real-time data are only for product analytics.

(I hope) No one in the article or this thread is suggesting your uptime or error metrics should be on a 24 hour delay.

Well I'm sure Apple would love to hear your ideas for remotely activating to unconnected FM chip inside the older iPhones

I'm 28 and I wish I were the most junior on the dev team. Being a "lead" developer is fun, but I wish I had more people who I can actively learn from just by being around.