Clojurians Log v2

Not quite the same, but just last week I arrived to the (common) epiphany that I should start learning how to really use google sheets (data validation, automatising data input) because it’s the fastest way to get non-technical people at my company to give me sane data

They already use sheets, and so far I’ve build tools for them as clojurescript web apps. I think I would have saved myself a lot of time had I done it on sheets instead

Been learning Rescript as a promising production language, through some discussion a user shared this article with me https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/. Was curious if there’s any solid counter-arguments? Seems to make sense to me overall but I don’t have a lot of experience with typed languages to begin with.

I was able to use cljs in my first week for a production project but trying to find something the other team members are excited about with similar productivity benefits, but that’s a discussion for another time 😛

> It skirts too close to calling this a fundamental limitation of type systems, suggesting that it is not simply inconvenient but impossible to model such systems in a nominal, static type system. It's possible to write the same programs in turing complete languages regardless of whether they are statically or dynamically typed. Generally, which language is the best fit is more about how a language makes a program easy to express or how a language makes a program difficult to express. I think a more compelling argument for dynamic languages like clojure is that the tools for parsing, verification, validation, etc. are available a la carté, usually as libraries. The programmer has the flexibility to parse, verify, and validate whenever, wherever, and however they choose. Typically, statically typed languages have less flexibility. I've attempted to try Haskell multiple times and the main roadblock I've run into is that I've never been able to set up a REPL friendly dev environment. The constraints on when, where, and how types are specified make REPL driven hard! (I haven't tried lately, would love to know if things have changed.) Another argument I've heard is that the static type systems often don't express constraints that are important for a domain. The common example is that [a] -> [a] provides little value, but makes the type checker happy. In Clojure, when you express constraints, you have several options to choose from. For example, spec allows arbitrary predicates. Since I don't know Haskell that well, I'd love to hear if this argument actually holds water. This doesn't apply to all dynamically typed languages and programs, but it's more common in dynamically typed languages to program using Plain' Ol' Data. If you use a library, you don't really have to worry that it will return a data type that can't be easily passed to another library. If you want to split up your program, distribute it across a network, or simply store some intermediate results to disk, it's straightforward serialize your data. Again, I'm not particularly familiar with Haskell, so maybe Haskell makes that easy, but it's usually a pain in Java or C++. I think the static typers would argue that two different libraries are unlikely to have compatible data and that static typing would actually help you coerce comparable data types, but I'd much rather coerce a nested clojure map than a nested Java class. How does Haskell handle collecting data? If want to package A, B, and C in clojure, I can do {:a A, :b B :c C} . Would that require a new type in Haskell? If later I also wanted to provide D? What happens?

I understand it is deathly practice to route queries from the client directly to the database. But, • Datomic has database functions which already understands the query. I don't have to parse the query before applying domain logic. • DB functions can store arbitrary transformations and validations, which can act as middlewares of sort. • Datomic's datalog is just plain old edn. So can I get away with passing datalog edn from the client directly to datomic and through my database functions I authorize and authenticate the request? Before allowing it to query or mutate the data?

nah, not really - there is always a query you can throw your db that will bork stuff

take a long time or whatever

if its "secure" and you control entirely the machine sending the query then its the same as any other machine just connecting to the db

Hmm, but I guess only with Datomic we can even try to think of such a possibility.

Oracle v Google opinion has come down in favor of Google.

Is that the one where Oracle tried to claim copyright violation on the Android OS or something?

Perhaps means this https://news.ycombinator.com/item?id=26699106

As I understand it, it's basically the question of if an API, (in this case Java's API, which Google copied to make Android), is copyrightable and it seems like the answer is no

> To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.” Pp. 11–15.

They assumed the opposite of that.

Yep, they copied headers from Apache Harmony to make Dalvik. Maybe it doesn't matter for the lawsuit but I found interesting this bit from the wikipedia article:

Sun offered a licensing deal of between US$30 and 50 million. Schmidt said Google would have paid for that license, but they were concerned that Sun had also requested some shared control of Android along with the fee.[9][10][11] Google states that they wanted more control in order to open source the language and allow third parties to take better advantage of its code;[9] Oracle states that Sun refused because Google's intention was essentially to fork Java to a Google version of the language, and to prevent it being inter-operable with other versions, an idea which was "anathema" to the "write once run anywhere" basis of the language.[12] Because of these differences of view, the negotiations failed to reach a deal and Sun refused Google a license for Java.[12]

oh woops

Man! That is outstanding news. I hope this lifts all the FUD over the language and the ecosystem.

(and through the use of developers using APIs)