141–150 of 200 posts
Earlier quoted context omitted.
What Scala problems does Kotlin attempt to fix?
Let's not go into the rabbit hole of "Scala has no problems"
I don't have a horse in this race but I find it interesting that in my career I've seen a lot of bad code but the worst clusterfucks I've met where all in Clojure while the community seems to be chock full of purists and in general people that takes craftmanship seriously at least at face value. ¯\_(ツ)_/¯
What a passive aggressive comment. > At least at face value Implying that in actually they are what a bunch of incompetent hacks?
Earlier quoted context omitted.
Are you implying Clojure is not simple? Have you ever watched Rich Hickey's "Simple made easy" talk? If you haven't, I highly recommend it. Disclaimer: It's not about Clojure.
I haven’t watched it, but I have heard about it. In contrast to the simplicity of a programming language in the happy path, I’m talking more about simplicity in the case where things break. For example, Python doesn’t implement tail call optimization in part to eliminate stack trace collapses. On the other hand, many reasons my current tool stops working is due to the underlying configuration of the JVM. Configuratio…
Clojure it's not (just about) beautiful and concise code. There's a lot more to it. And JVM in my experience is not a problem. I was skeptical at first, but as it turned out - JVM is pretty stable and solid piece of tech. Besides - there's also Clojurescript (and less popular Clojure CLR). Depending of what you are trying to solve, you can go that route too. I may not convince you to give Clojure a try, but please do yourself a favor and watch/read Rich Hickey's talks. https://changelog.com/posts/rich-hickeys-greatest-hits They are perfectly applicable and do make sense even outside of Clojure context. Many developers characterized those talks to be "eye opening".
It's interesting that the very things that attracted the author to Clojure was what kept me from moving to it from Python. I enjoyed the syntax. Loved the immutability. However, I wasn't able to understand the structure of program data at a glance even when reading my own code. The reliance on lists and maps everywhere meant that the structure of data was encoded in the code of the functions that created it and somet…
The fundamental problem with S-expressions is that they are intended for (1950s) machine readability and human ergonomics takes a back seat.
Earlier quoted context omitted.
What a passive aggressive comment. > At least at face value Implying that in actually they are what a bunch of incompetent hacks?
That the results didn't match the values. Disconnect happened for reasons I didn't fully understand. On a second observation I must have touched a VERY raw nerve given the huffy reactions.
>I don't have a horse in this race but
This is like someone saying I'm not racist but... After which they tell you why they really hate black people. You clearly do have an opinion your statement is a plea for imaginary objectivity.
You follow it up by elevating anecdote to analysis without the work required for real insight. The crack about at least on its face is just designed to offend. The silly emoji after doesn't soften what is basically trolling. If you want to seriously discuss you should start by making substantial points.
Earlier quoted context omitted.
Just think of the parenthesis as loving warm homoiconic hugs.
Hehe, when teaching my 8yr-old programming (in Python) I call (function call) parenthesis a hug to explain that a function "hugs" all arguments to it. She seems to get that :).
Earlier quoted context omitted.
rails/Django -> luminous Flask -> pedestal/clojupture Relay -> fulcro Pandas -> clojure.core, specter Keras -> mxnext/neanderthal
The only one I miss in Python that is not in any other package is matplotlib. Is there any clojure alternatives?
Earlier quoted context omitted.
For us, the answer to "R vs Python" is "Spark" since eventually you get to dara sizes where just R and Python don't really work.
> where just R and Python don't really work. From the Spark website: "Write applications quickly in Java, Scala, Python, R, and SQL".
There's limited interaction with pandas but that's about it - you don't get R statistical algoritms for example.
Earlier quoted context omitted.
sure, because Sure, because this (taken from React's JSX example page): Scores ; is more readable than this: [dashboard-unit {:data-index 2} [:h1 "Scores"] [scoreboard {:class-name "results" :scores game-scores]] Please tell me more about Lisp readability.
I don't really see how JSX informs us about readability of s-expression vis-à-vis Python et al. Disregarding that, and in my opinion, properly formatted JSX might be a bit worse then s-expr for shorter stretches of code, but if/when you have a longer stretch, the visual symmetry in JSX would seem to tip the scale the other way. If there is a point to JSX, I would claim it's mostly that it looks different than the sur…
The point of the syntax isn't necessarily that everything looks the same, it's more around why that's the case and what other properties it enables. In other words, if a homogeneous (and arguably less convenient) syntax is the downside, it's important to consider the upside too. This still not make it 'better' enough for to want to use, but maybe will shed some light on why reasonable people might think differently.
The core concept behind Lisp syntax is that Lisp has a handful of core data structures, and the user syntax of the language is defined directly in terms of those structures. Clojure uses sequences, vectors, hashes to do things like represent blocks of code, argument lists, and type declarations. The structures used for this are the same as the structures uses in user code, and what you type in to the keyboard when you program are the normal textual serializations of these structures.
So this gives a couple of benefits:
1) The character sequences used to represent the language are easy to parse in a structural way without a whole bunch of parsing logic. A structural editor for Lisp doesn't necessarily need as complete a grammar or parser to enable the structural features as does a language like Java, Scala, C, etc.
2) It's easier to generate or manipulate code. Most famously, this enables things like macros. Macros and code transformations are absolutely possible in languages like Java and the JS ecosystem, but less commonly used and more expensive to develop.
There are many other examples of where these properties come in handy, but JSX turns out to be a reasonable illustration of why these are useful. Adding something like JSX to Javascript requires an explicit preprocessing state. Then, it also requires specific editor support to deal with the modified syntax. Once all that's done, what you have is a wrapper around 'React.createElement'.
It says a lot about the value of application-specific syntax that people are willing to pay those costs to get a certain syntax, but the Clojure/Lisp approach (hiccup for markup) reduces the costs and makes that kind of thing significantly easier to do. Whether or not that's the tradeoff you choose to make is one thing, but there are reasons to make it.
Earlier quoted context omitted.
Clojure works on the JVM so you have native access to all of the Java ecosystem. With that in mind I'd say the libraries are actually better for Clojure with the exception of data analysis. I don't think there's a language out there that has as many data libraries as Python (like Pandas).
I really don't understand this point about just using Java libraries in Clojure. Why not just use Java? Wouldn't the experience of writing Clojure that fits the Java library's model be horrible?
What happens in my experience is that Clojure programs do tend to encapsulate more extensive use of Java interop into their own modules. For more standard or commonly used packages, this means a canned library or similar. (But this notion of abstracting out APIs is just good software engineering in general, and not really specific to Clojure or anything else.)