This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-16
Channels
- # announcements (33)
- # atom-editor (1)
- # aws (21)
- # babashka (174)
- # babashka-sci-dev (2)
- # beginners (59)
- # calva (4)
- # chlorine-clover (9)
- # clj-kondo (51)
- # clojars (7)
- # clojure (86)
- # clojure-czech (4)
- # clojure-europe (21)
- # clojure-france (6)
- # clojure-nl (1)
- # clojure-uk (2)
- # conjure (7)
- # core-async (3)
- # core-logic (3)
- # cursive (10)
- # data-science (8)
- # datalevin (14)
- # datomic (12)
- # events (1)
- # fulcro (5)
- # graalvm (10)
- # gratitude (3)
- # honeysql (3)
- # hyperfiddle (3)
- # introduce-yourself (4)
- # joyride (3)
- # leiningen (3)
- # malli (13)
- # minecraft (15)
- # music (1)
- # off-topic (40)
- # pathom (16)
- # polylith (28)
- # portal (25)
- # rdf (15)
- # remote-jobs (3)
- # shadow-cljs (23)
- # specter (1)
- # sql (5)
- # tools-deps (25)
- # xtdb (31)
Interesting. Adobe built their ColdFusion "Builder" IDE on top of Eclipse back in the day and they are rebuilding it on top of VS Code and they've said they are also going the LSP route. They'll be showcasing the new VS Code/LSP "Builder" IDE at their online Developer Week in late July I believe. LSP is pretty amazing.
Aye, the increasing assumption that you're always able to tap into "servers" running somewhere (even if they are local) is one I tried to fight for years but I've kind of rolled over and accepted it at this point 😞
OmniSharp Server...
I wonder if Omni
was used because it's omnidirectional or omnipotent... or both :thinking_face:
Also I'm not sure why but this dislike ratio is insane:
Edit: Upon reading more comments I'm very sure why.
I don't expect good behavior from msft on this, if the refterm saga can provide any reference
I think that the word "omni" was used not to show that they will have one server but that they want to force devs to pipe their code through their server's "AI" (which obviously is closed-source and probably heavily based on github's copilot). IMO this means that they want to collect data about the projects that are currently in-progress and make a data collection pipeline out of it. And then use "live code reload" as a "nice feature" that nobody can say "no" to for marketing of this new model. This way they could collect data and try to figure something out from it. They already have copilot on github and this kind of effort plays nicely with what they have. For instance this response from OP only solidifies it: > new host component is the bridge between open and closed source functionality https://github.com/OmniSharp/omnisharp-vscode/issues/5276#issuecomment-1157130770
This comment talks about their Python extension: https://github.com/OmniSharp/omnisharp-vscode/issues/5276#issuecomment-1157366249
> If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. The point here is that the human potential manifests itself in individuals. To realize this potential, we must provide a medium that can be mastered by a single individual. Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. > Dan Ingalls, Design Principles Behind Smalltalk
@UFTRLDZEW you realize this requires the death of client server architecture and saas, right? (I'm okay with it btw)
I've been sold on that idea ever since I first watched Bret Victor's The Humane Representation of Thought
Let me ask - if you have an open source client to a closed source server, and the whole product depends on the server results to be meaningful, isn't that a closed source system? It feels like "a pure function that calls another function that does IO is essentially an impure function" right?
That's like saying that any software that runs on windows or mac is a closed source system because it relies on closed source Windows or OSX APIs. I think there's more nuance here.
> The point here is that the human potential manifests itself in individuals. To realize this potential, we must provide a medium that can be mastered by a single individual. Clearly, there are systems that are built to target teams rather than individuals. It's not to say systems for individuals aren't important, but systems for teams are important too. why not both?
So much OSS is either created by or heavily support by companies that make their living off proprietary software systems. I don't think we can (or should) be "purists" about it, realistically. "Pure" open-source, completely free of corporate involvement, is almost impossible because the infrastructure for software -- from the hardware we use to develop on, to the networks we communicate across, to the servers we host everything on -- are all corporate systems to a greater or lesser degree. Contributing to OSS is nearly always a luxury afforded us by the corporations that have paid us, collectively -- that we can afford the hardware, the network connectivity, the hosting to do it. That contribution is impossible for a lot of people who aren't in our collective financial position...
Unless we go to the root of the problem and set our goal to be a human friendly personal server While not a purist, when given the choice of more or less open, I'd always pick more
@U7RJTCH6J I'm not sure I see the relevance of the distinction. A system that can be understood, mastered, and extended by an individual can be understood, mastered, and extended by a team, as teams are made up of individuals.
@UFTRLDZEW , right, but there are systems built for teams that would be unwieldy for individuals, and that's ok
@U7RJTCH6J that's not what I meant. Like, at all. Look at the definition of free software; even if a free software runs under windows, an individual have full access to the source code and can port it to another system if he wants. In the case of this C# situation, yes, you can port the client to anything you want, but you don't have access to the full picture because the server (and the way it works, and how it correlates things, etc) is closed. So even if you port every open-source part to something else, it will still not work. That's the issue I'm pointing...
It's the same situation: In the case of this Mac OSX/Windows situation, yes, you can port the application to anything you want, but you don't have access to the full picture because Mac OSX/Windows (and the way it works, and how it correlates things, etc) is closed. So even if you port every open-source part to something else, it will still not work. This is especially true if you heavily rely on platform specific APIs.
You could choose to use open source implementations of the platform specific operating system calls, but the same idea applies to reimplementing or finding open source implementations of server APIs
Would it make sense to create #idioms channel to discuss & share various clojure idioms (like seq
vs (not (empty?
😄 )
Wouldn't be enough to just pin somewhere a link to https://github.com/bbatsov/clojure-style-guide#idioms?
It actually sounds like a MOTD thingy that could be sent to users periodically :thinking_face: Edit: and it could also enable them to achieve their golfing needs
I think a channel is a great idea. A link to guidelines is great, but nothing helps as much as conversation and discussion, much the way having someone read a textbook isn't as useful as discussing the topic. Idioms are such an important part of a language and are often distinct from the generic "how do" of other questions.
does anyone have a favorite solution for feature flags? esp. open source; I'm looking for comparisons to launchdarkly
Funny, I'm starting work on something like this here too. We'll be taking a look at solutions: • https://github.com/lambdaisland/pennon • https://github.com/yeller/ (historic, old, but still!) • https://docs.getunleash.io/user_guide/quickstart • https://github.com/AppsFlyer/unleash-client-clojure
If you find anything else of interest, please share! BTW with OpenTelemetry (e.g. https://honeycomb.io/) it becomes trivial to project observable statistics of the impact of changes.
yeah, we use honeycomb already. something with easy integration with it would be great!
We built in-house feature flags at the tenant level. We enable a feature flags separately for each tenant, and since we dog-food our own solution, we get to run "bleeding edge". Perhaps I'm missing some of the features but in our case it's essentially of maps of falsey/truthy values inside a tenant's info that gets loaded on every request anyway.
that's basically what we have rn. the things we're working through is: 1. they aren't plumbed through to the UI yet, so we need to do that to support rolling out UI features 2. we want to do things at the role level as well as tenant level, e.g. "turn this on for everyone with admin access" 3. we want an audit log of who toggled what for whom 4. we want analytics on what code paths have been actually used over time
Something to consider is that (at least) launchdarkly seems to be popular enough to get caught in Adblock filters. I wouldn't want to block my UI based on reaching out to their script and third-party servers. You can probably work around this though.
I was wondering about this. We’re building something small in our codebase. Migrating some day to AWS’s flagging or a third-party only if we see so many needs…
Let me ask - if you have an open source client to a closed source server, and the whole product depends on the server results to be meaningful, isn't that a closed source system? It feels like "a pure function that calls another function that does IO is essentially an impure function" right?