Fork me on GitHub

I discovered Good solution for when you run certain services you need during dev on a box at home, and you want to access them from a coffee shop on your laptop


Is it shorter and less deep than a normal tower? That sort of thing would be ideal for my home vmware box rebuild if that's the case


I need something shortish and quiet I can put next to the TV


Oh wait, I probably can't put 5.25" drive bay caddies in that can I?


I looked at the Intel NUC line, I think I’ll use that for a home server


I need something big enough for at least 4 3.5" drives, preferably with room for expansion in the future. And even though I don't pull them very often I want to have them in hot-swappable drive bays, not screwed into the inside of the case


These days it seems very hard to find a case that you can put a drive bay or two into, unless you want to get an actual blade server. And I don't have space for a rack, nor do I want the noise a blade server makes right next to the TV


At the moment I have an ageing Acer Revo for the TV and a smaller file server host under the stairs, but I want to merge them into 1 box that I'll do VFIO and a whole load of VMs on


what about USBc?


zerotier… why did I only discover this now… it’s great!


Hah. My current desktop is in a CM Stacker v2. So if all else fails I'll use that when I upgrade the desktop 😉 It is quite huge though, I was hoping to find something a bit shorter and maybe squarer. But I realise my requirements are very... unusual


Any opinions against default methods in interfaces in java?


Ehh. Inheritance conflicts. I understand why they introduced them, but it just seems to me like the concept of the interface was compromised.


I'd argue that the concept was extended in a pragmatic / positive way. It makes my life easier as a programmer.


(slippery slope ahoy) Copy paste also makes a lot of people’s lives easier at first.


Everything has a cost and a benefit and it’s up to you to decide what you use based on those. I gave you an example of a cost, not a wholesale condemnation of the concept and an argument to never ever use it. (General principle being in this case: if you relax previous guarantees, whatever relied on these guarantees is liable to fail, unpredictably.)


At least it allows interfaces to change after the fact, which makes them more open than before and therefor its possible to change them when they are released. Reminds me of clojures maps in some way.


@seancorfield curious to hear your strong opinions, especially since you must have more experience with these problems than me


I think, I know the feeling. There definitely are programmers with short attention spans, that will lose interest before reaping benefits. Rich's "think deep before doing" approach might not suit them all that well.


yeah, and it's not like the current job market is giving programmers any incentive to get better 🙂


by "get better", I don't mean agree with me, I mean reflect deeply on their craft


OTOH, many programmers will use a similar stance, even if they could handle it, if they just don't want to, for some reason or other.


There's an overall "background problem" which is that as computing has become more and more ubiquitous, the industry has hired ever more programmers and the overall quality has dropped -- by necessity of supply and demand. But even going back 25 years, I saw a lot of businesses that used compute-heavy systems, tended to hire by volume, rather than quality, and part of that is cost and perceived value.


The "average" developer today doesn't have to be very good. Java has been designed to make "average" developers productive, by trying to make things mechanical and providing plenty of guard rails.


We have more programming languages than ever, we have more industries involved in programming than ever, through sheer weight of numbers, the vast majority of developers aren't going to "have enough architectural skills to benefit from"... anything that is somewhat off the beaten track. But that's not about static vs dynamic typing, that's just about language features in general.


Haskell, Clojure, and several other languages tend to self-select for developers who think more about problems. Because they require effort to learn that mainstream languages don't require. Ruby and Python (and PHP) are very widely used dynamically typed languages that don't depend on architectural skills. Java doesn't depend on architectural skills either.


> Because they require effort to learn that mainstream languages don't require Don't you think that's a very circumstancial thing, i.e they require more effort merely because they are different from the mainstream? I don't see any objective reason why Clojure would be conceptually harder than Python to a complete beginner


For complete beginners, and an environment within which to be mentored, yes, Clojure is a perfectly fine first language. But because of the demand for Java and JavaScript, colleges teach those languages, and so even a college graduate already has those OOP/mutable state biases -- and they're not complete beginners.

Philip Hale04:06:05

> Ruby and Python (and PHP) are very widely used dynamically typed languages that don't depend on architectural skills I wonder what you make of this argument: Ruby requires more architectural skills than stricter languages because it's pretty unopinionated. It takes discipline and experience to know how to architect things well in multi-paradigm, highly dynamic languages because there's nothing in the language forcing any particular style or pattern.


To really use any language effectively requires substantial skills and/or experience. My point was that getting started with Ruby, at least in the context of Rails, requires very little knowledge at all -- and a lot of RoR sites got built by people with next to no architectural skills.

👍 8
Philip Hale05:06:28

That makes sense


I have the impression that Clojure is a very good selector for the right kind of people to work with. I have talked to Haskellers and Erlangers a lot and I think they are way less pragmatic where it matters. On the other hand Clojure is alien to a lot of conventions, so you get people who are able to think out of the box. That is important in any business problem as well.


This argument can be communicated to management more easily than the more techie ones about architecture, I think.


To be a bit more concrete, all the devs who didn't want to join our Clojure company have proven to be fairly ineffective and in a sense Clojure is a very good idiot filter.


I would not say it that way in general, but this argument seems to work.


To be totally frank, I also am a bit frustrated by talking to Haskell people about Category Theory and theorem proofers and so on. I think they overestimate the generalizatoin capabilities of their formalisms in almost any domain (e.g. statistics, distributed databases, optimization). I have recently taken a look at HLearn again and I don't know how they can claim to do anything really helpful, yet they claim to be more ambitious than Julia. Many people in this field seem to have a strong belief into formalisms that has nothing to do with empirical thinking, for a lot of definitions of empirical (e.g. applied statistics).

💯 4

I would not want to work with these people, even if they are super smart in some aspect.


@U1C36HC6N I can see where they're coming from: my background was mathematics and a PhD in functional programming language design (and implementation) and for several years after venturing out into the real world, I desperately wanted FP to "take over" since it was "so obviously the right choice". When Haskell appeared, I was convinced it would take the world by storm. I mean, it was right and who wouldn't want their programs and their technology to be right, right? 🙂 Since then, I've developed something of a love/hate relationship with Haskell. Given Erlang's origins, I would have expected them to be much more pragmatic, so it's interesting to hear you lump them in with Haskell... I've dabbled with Erlang and had no exposure to their community.


Well, I think Erlangers are more pragmatic in a sense that they care about building reliable systems for the real world and less about proper language abstractions and the formalism they use. But they have difficulties to realize that maybe Clojure is a better language for instance to build distributed databases. I am inofficially participating in and their database is build on Erlang.


I have tried to convey that Clojure might be a better idea, but they are similar to many islands that I have met, where people want to basically stick to a camp that is right, because it gives them a good feeling. They have enough good reasons to justify Erlang, but it made them somewhat fairly pissed when I pointed out that Amazon is building a very reliable database in form of DynamoDB with plain Java and riak is just a clone of it. I understand their frustrations and think Beam is cool, but it is a very marginalized runtime with a very restricted programming model and not easy to connect to business problems.


It might have been my fault, but I have the general impression that Erlangers live in their own universe.


Having a PhD in FP design is pretty cool. I will pursue one in applied statistics with Anglican


I am not at all against CT or formal thinking, but I think putting the type system first has a big price. I really do not like when it takes my evaluation environment from me. I learn a lot more by playing with values than by playing with types.


It is a constant danger in mathematics (and other disciplines) to fall in love with your own formalism and in the Haskell community I have real difficulties to get people to show me how I get more productive with it. They talk more about how it is the right way in an abstract sense, but Rich is right there, I think. Correctness is more and something different than self-consistency.


I wish Clojure had a practical optional type-system. I see value in types and I like aspects of what people do in Haskell and how you can use a type-system for formal reasoning. When you implement an algorithm or a datastructure this can be really valuable. But it is not the most important thing in most problems, even in implementing an algorithm. The combinatorics people I know from university still use C for good reasons. Same for numerics, good algorithms are ugly and exploit all kind of imperative low-level hacks to perform well in many corner cases. And that is just math itself, not even some messy application domain.


@seancorfield I think you have mentioned that you have used core.typed but it was to cumbersome, right?


Yes, we tried it. Several times. We also tried Schema, several times. We went back and forth between them a few times, and finally ripped it all out.


core.typed was very painful to use. If you annotated any functions in one namespace, you had to annotate everything to avoid the flood of warnings (even if it was just "don't check this"). And the type inference wasn't strong enough for idiomatic Clojure so we had to refactor some code just to satisfy its type inference/checking. In fact, I just ran across a function yesterday that looked really odd and had the comment ;; this is ugly to satisfy type checking


And Schema only does runtime checking so it's only as good as your test suite (unless you leave the checking on in production as well -- but that has an overhead and you essentially just get a different runtime exception to not having it, in a lot of cases).


Type checking Clojure is hard -- and core.typed is an incredible piece of software. But I just found it too painful to use.


We use spec in a number of ways that are different to both core.typed and Schema. We use it to generate test data, to support testing the "contract" of functions, to specify the shape of data in explicit validation/conformance (for example, API input parameters) and for auto-generating CRUD code for MySQL based on specs of the tables.

Philip Hale21:06:11

> If you annotated any functions in one namespace, you had to annotate everything to avoid the flood of warnings (even if it was just "don't check this"). And the type inference wasn't strong enough for idiomatic Clojure so we had to refactor some code just to satisfy its type inference/checking. Exactly my experience with Flow


Yes, my attempts at using core.typed failed already with Java interop. I think its spec and type inference from tests is interesting though.


I would love to use it, but probably it is related to the fact that Clojure is difficult to type check that it takes so long.


@seancorfield have you studied core.typed's codebase?


I think for me core.typed would also be useful to check consistency in some of my formalisms/algorithms while being permissive at the borders (I can imagine just using spec in general and specing the parts where I see problems.)


I think it is important not to go for a consistency model of the whole world that you have to type check before you can do computation.


@seancorfield Which core.typed versions have you tried? I am playing with 0.5.2 now. One annoying issue right away is the lack of proper annotations for nilable/non-nilable Java types. But I guess it is not the main issue. The main issue is rather the lack of core.typed's support for all idiomatic Clojure expressions (that is at least the main complaint in the CircleCI post).


The recommendation is to use clojure.core.typed/tc-ignore deliberately to port namespaces, but my impression is that this still means you have to add it almost everywhere in the beginning, which is a bit annoying.


Sure, if a developer has those skills, they can write better systems -- in any language -- but we've moved to a world where most programmers are, unfortunately, a commodity. Fungible. Almost unskilled.


from another view point, it's also fair to say, that the problem is tech being a jungle of non-interopable systems, and abstraction holes that are barely visible, until you fall into them .. that's not something solvable by skill, only sheer, lifetime - costing experience ...


Right, the systems we build have become much more complex over the years. When "web development" first appeared, it was easy -- pretty much anyone could write a website or small webapp.


e.g. imagine, if every driver needed to be qualified to take part in races ..


and FWIW, I feel that as a hosted language, clojure is rather prone to the abstaction-hole problem ...


PHP (and ColdFusion) are good examples of very easy-to-learn tech providing an on-ramp for non-technical folks to become web programmers. And so we've seen massive, complex, and unmaintainable systems produced by such folks -- through no real fault of their own, rather the systemic problem that businesses see a lot of this as "easy" and therefore they can just keep hiring and throw more bodies at a problem.


yeah, the value prop of those being that you can program without any idea of what you're doing, by imitation. I can see how Clojure is not like that


The industry expects large teams of (mediocre) programmers. That's where we went wrong -- decades ago -- and there's no putting that genie back in the bottle.


About 10 years ago my team lead told me "we're not software engineers, our job is to apply Microsoft's standard practices to our company's problems".


Seems to be less and less viable though. I mean, my current company is mostly PHP, and they're really struggling to hire PHP developers


How are they struggling? Hard to find PHP devs? Or hard to find PHP devs qualified to solve their problems?


@tbaldridge a bit of both I guess, but they're not being too picky IMO. The thing is, even in PHP, the demand for devs is completely disproportionate to the supply


(at least in my location / industry)


Yup, demand is far outstripping supply -- and will continue to do so.


But in many ways the demand is artificially too high (because of the reasons I outlined above).


@tbaldridge I've heard that sort of discussion at Java conferences, listening to folks from teams of EJB/Spring/whatever "enterprise" Java developers. Just keep churning that handle.


I attended a talk on CI/CD at one Java conference a few years ago and I listened to attendees as they left the talk: most of them seemed absolutely blown away by the possibility of continuous deployment...


and now with docker it's even easier! (although some people hate docker, and those people are wrong.)


> But in many ways the demand is artificially too high (because of the reasons I outlined above). @seancorfield you mean, because the industry creates developers with a "negative" contribution to the supply on the long term?


I wouldn't say negative but I think industry as a whole has very low expectations of what a team of programmers should produce.


I have a hard time finding web developers that have even heard of the OWASP top 10.


Granted these days you have to know a lot more than 20 years ago, but it's really hard to find skilled developers.


regardless of language / platform / stack.


> I wouldn't say negative but I think industry as a whole has very low expectations of what a team of programmers should produce. to be fair it is sometimes a challenge to find programmers who dont need to be handheld through everything. But finding a group of coders who work together really well and intuitively know what they're building. that's the best.


(throw in a designer or two who are on the same wavelength and you're onto magic)


Some companies do business by doing projects that increase in complexity, never end and require large dev teams to make any progress and also similarly large ops team to keep the running system alive. Customer pays the whole bill of course. Also you need to have a league of managers to mentally wrestle with the customer to continue the nonsense as long as possible. Inexperienced programmers are perfect fit for such situations. 🙂


That’s already quite distant from software engineering which is probably what we’re supposed to be doing.