I remember doing just that - writing some ugly parsing code, thinking that I should be a good team member and add some specs for what I was doing, and when I tried calling conform... Oh, it did the parsing for me!
Depends on the cheese, and on the usage, really. My mom works at a cheese factory, so I regularly get more cheese than I know what to do with, so most of it ends up in the freezer. Non-aged cheese (not familiar with the English terminology, sorry) is absolutely no problem to freeze in my experience. Aged cheese, at least the ones I eat, crumbles completely after defrosting, absolutely impossible to slice - but I only use aged cheese for pizza and other stuff that goes into the oven, so the fact that it falls apart just by touching it is more of a feature for me - no need to grate it!
That's why I prefer to listen to podcasts when taking walks etc, rather than full-on audiobooks - if my mind wanders and I start thinking about something else, it's not a big deal if I missed an episode of some tech podcast. With an audiobook, I have to try and find where my mind left off! (which is usually a lot more cumbersome than when the same thing happens while eye-reading)
This has been my experience. I managed to switch to working remotely 100% by saying "I need to move to another town, either I start working remotely or I'll need to switch jobs". My boss wanted me to say, but not enough was done (by anyone, me included) to really make it work. I wasn't let go, they were still happy with me, but I decided to leave after about half a year, even though there were definitely aspects of working remotely that I loved.
What had kept happening was that services written by my team (mostly doing Clojure for backend development) were taken over by other teams that either weren't interested in learning Clojure, or weren't allowed by management to do Clojure development (for whatever reason), so each time this happened our original service would be rewritten in Java or Node.
...of course, for the other team to be able to do this, they still needed to learn some Clojure in order to understand our code, but even in the cases where they actually liked doing Clojure, they were still forced to do the rewrite. The company was/is expanding very rapidly, so part of me can understand the decision to narrow it down to fewer "allowed" languages, to allow services/responsibilities/teams to move around more freely.
But it was one of the main reasons I decided to leave the company. I had joined after years hoping for Clojure to be my main professional programming language (for a substantial part of my career, at least), and I left a somewhat more bitter developer, but at the same time feeling a bit more free and relaxed - there are sooo many opportunities to pick from, now what I'm a bit more open when it comes to the tech!
I agree with what you're saying, my post was mainly trying to point out that there might appear to be more Clojure jobs than there actually are. For the past couple of months, I've been looking for Clojure jobs (after my company in one fell swoop decided that Clojure was out, and we were no longer allowed to use it for new projects), and though there are quite a few matches when searching just for "Clojure" on job boards, most of those have nothing to do with Clojure. Out of 50-100 matches, maybe 2-4 of those were actual Clojure jobs. Granted, this is in Stockholm, but the situation was pretty much the same a couple of years ago, and things don't seem to have improved. I love Clojure, it's probably my favorite programming language, but I finally decided on a more normal C#/Java/JS position for my new job.
In my experience (in Sweden), most of those results are "false positives". Companies/recruiters like to look for passionate programmers, so they put smaller languages like Clojure in their ads, even though the job itself has nothing to do with it.
RSS is one of the main ways I consume the web (including HN). Been doing it for years and I'm very happy with it. I don't know anything about how it works, but it seems lightweight in that I can keep using it without any problems even now when I'm in China, going through terrible internet connections which prohibits "normal" web usage (in addition to The Firewall, that is).
I would say that one of the main reasons why F# gets comparatively little attention is that, yes, C# is being evolved with a fairly big focus on taking lessons from functional languages. Pattern matching is coming along (though it will probably never be as powerful/expressive as in e.g. F#), C# 8 will have nullable reference types, essentially providing null safety in the same way as Option, immutability is being touted as a Good Thing (I hope record types will be with us soon), etc. As someone who loves functional programming, C# is without a doubt my favorite not-mainly-functional-language (and it's way up there overall).
Compare this with Java and the functional JVM languages, where Java didn't even have lambdas until fairly recently - no wonder a (relatively) large subset of JVM developers focus on Scala and Clojure.
C# 8 will introduce nullable reference types, which will effectively be equivalent to Options. And they are working on pattern matching (some simple, partial implementation is already in place AFAIK), though I don't know what will come of that.
I'd like to point out that the extension method feature of C# is one big reason why I like this whole story much better than the Streams API in Java. There are often methods I wish were part of the IEnumerable interface, and with extension methods, I can add them myself! (if they are not already provided in, say, MoreLinq [1]). Very convenient, and a big boost in productivity.
I've worked a lot with both C# and Java, and C# is so superior I never want to touch Java again. Especially since around C# 3.5, the distance between Java and C# has grown enormous. The two benefits I can see with Java is that it's a smaller language (easier to train junior engineers), and yes, the huge amounts of libraries.
Kotlin/Scala/Clojure are nice, but my experience is that just because an organization is working with Java, you shouldn't count on being able to work with some other JVM language. At my current job, we've been forced to give up on Clojure (a language I love) because the higher-ups have decided we should stick to Java.
I really hope especially Kotlin will gain more traction in the coming years, but in the meanwhile there is at least an order of magnitude more jobs in C# (where I live).
Agreed. I've worked for many years as a software engineer, and some of the most challenging stuff I've done has been building robust test automation frameworks. The amount of disrespect QA gets (both those focusing on automation as well as those focusing on manual testing) is disgusting.
I went with this approach on a recent project, for two reasons:
* Tracing/history/auditing
* Structuring the service around these events, it became trivial to add new "event types", rather than expanding some big hairy PATCH endpoint or similar. In other words, when I needed a user entity to be able to belong to a group, I just added a new event type, "user/join-group". Having a single endpoint for all events had two other nice benefits: batching became trivial, as well as doing several events transactionally (all events in one requests are processed in one transaction).
It's been running in production for a couple of months now, and it's been working great! The main drawback I can think of was that it obviously didn't work well with Swagger out-of-the-box, had to do some custom handling for showing all the available event types.
IMO it's completely inferior to LINQ in C#. One of the main reasons being that Java still lacks extension methods, so you're stuck with the methods that are provided for you. In C#, if I want a Dedupe in my LINQ method call chain, I can simply implement it myself.
Maybe see with your employer if you could start working part-time? Taking two hours off every day, or one day per week or something like that might be enough to help move your project along. Best of luck!
I really recommend the Japanese For Busy People books, I learned tons from them quickly. They start off very basic (obviously), but they explain the grammar in a really good way, and progress into more advanced topics as you go along. Make sure to get the kana versions, not romaji!
For learning Kanji, the most efficient option I've found is Remembering the Kanji by James Heisig. It's a bit of a long-term investment, in that it takes a while for them to really pay off (you don't learn the readings/sounds until book two, the first one is completely focused on the meaning and writing of the characters), but in the long run I think it's a much better option than for example the books trying to teach you the characters by showing you their similarity to the things the represent.
* Visual Studio + Resharper for C#. Don't really think there are any realistic alternatives, although I'd be happy to try some out, my current setup tends to get slow.
* Visual Studio Code for JavaScript/TypeScript and React. I tried Sublime and Atom, didn't quite like them, haven't had any issues with VSCode since I started using it about a year ago. But I wouldn't be able to tell you why I like it better than the alternatives. I probably should.
* Eclipse + Counterclockwise for Clojure/Script. It doesn't seem to be very popular, and I've been meaning to try out Cursive and proto-REPL (and maybe actually get into Emacs), but I've been using Counterclockwise for years and I really like it. The Clojure data structure editing functionality is really neat, and I don't remember seeing its flavour of it in other editors. But like I said, I don't have that much experience with other editors.
Agreed. Especially when taking commuting into account - for me, one day off means 2 hours less commuting.
During the past year, I've actually started trying this out. I've taken a couple of my vacation weeks and spread them out - instead of taking one week vacation, I've taken Fridays off for five weeks. It's been amazing. Somehow it feels like that extra day counts twice: your weekend gets one day longer, and your work week gets one day shorter!
With regards to performance, sometimes taking the penalty of immutability in the small leads to gains in the large. The React wrappers in ClojureScript are a great example of this - since all data is immutable, shouldComponentUpdate is trivially and automatically implemented for you, meaning React not having to diff parts of the virtual DOM that are guaranteed to be identical.
There are other cases where immutability helps, even with regards of performance. At my day job, we use C#, with little focus on immutability. Performance has been a huge problem lately. One of the things we did was to change lots of constructors which initialized empty lists. In most cases, these lists remain empty, so we created a whole bunch of objects unnecessarily, which put a lot of toll on the GC. The "solution" was to initialize them to null instead, which made the code a lot more brittle and cumbersome. Had we used immutable lists instead, we could've shared one single, empty object instead (per type, of course).
We also have lots of copy constructors which we use often - these would be completely unnecessary with immutable data.
Yeah, but you're limited to a very small play area. Some slow-moving games get around this beautifully using teleportation (Budget Cuts is a great example), but it doesn't work in all cases. Wouldn't want to teleport my way around Fallout 4. The developers are trying different tricks to make it work, really hope they come up with something because the potential is great, but as it stands my Vive has been collecting dust for the past months.
I agree with you, and yes, F# does help you write safer code. My main objection is with people claiming that NREs cannot happen in F#, which is simply incorrect - it sure happened to me when I was learning some F# and tried some interop (and you're not going out of your way in doing interop, using some external library or what have you). Which is fine I guess, but I think it's important to be clear about the benefits of the language when recommending it.
I've mentioned this before, but it's worth mentioning again: unfortunately, F# is not guaranteed to be null-less. As soon as you are working with instances of some class (for example string), you are back to normal null checking. Of course you can wrap the string in an option, but it can still have a value which is null... So even if you don't have any kind of interop, you can still end up with NREs. So what you'll have to do is tell your teammates to not use nulls, and instead make proper use of option etc, and then you're back to avoiding NREs by conventions, not by the compiler helping you out. Am I incorrect in this?
F# seems like a very nice language, but honestly, C# is getting so much love from Microsoft that I haven't felt motivated to learn F# properly (the situation is very different in Java land). Seems like non-nullable references may even make it into C#, so there you go! :)
It's an interesting problem. I always strive to write clear code, but clear and obvious code for me could be confusing, weird and "clever" to others.
I joined a .NET shop two and a half years ago. At the time they were targeting the 2.0 runtime, so one of the first things I did was to include LinqBridge for all the Where, Select, etc IEnumerable extension methods. I'm used to functional programming so that kind of stuff is what I use all the time. Not everyone was familiar with it and got clearly confused, but they picked up quickly, saw the utility, and today everyone is onboard.
So, I think there are two sides to it. Of course overengineering without considering understandability and maintainability should be avoided. But you shouldn't shun or even forbid language features because you don't understand them. I know of places where async/await are banned because the programmers cannot be bothered to learn how to use it. That's not what I think the programming profession should be about. C# regularly gets new language features, and I make sure to pick them up and use the ones I find useful. If someone thinks we shouldn't use some feature, I'm happy to have that discussion, and I will abide to what my team agrees to, but the reason better not be "because I don't understand this feature"!