thepratt

> car.delete()

Your Porsche disappears before your eyes.

There isn't operator overloading as other languages have it, but you can write instances for your types. It seems you're just complaining about using vector addition operator (^+^) instead of a different addition operator (+); if it bothered you that much an instance would create a link defining + as ^+^.

I'm a big fan apart from how they version. Depending on when you install the version will point at a different commit hash. In our case, all of our Haskell builds failed on all but 1 machine (day apart in resolutions). How nixos handles environments meant our large package builds would kill the entire os, or underlying lib linking just failed - never figured out why, but it wasn't worth investing more time.

Have you run into design decision limitations with Elm yet?

We use PHP. PureScript Haskell Postgres :) all on kubernetes atop AWS.

Is there no room to fight management or make them understand?

Completely agree, it should always be team first.

Salaries depend on location. No one can give you an accurate measure without knowing location. Look at jobs you'd want to apply to in your area, some will disclose salary ranges.

I agree, it's more I hate x gem, or the community as a whole. https://news.ycombinator.com/item?id=5157886

Yes and no. For what I replied to is essentially garden shedding the language. The overall problem is grasping the concepts, weather or not you want es6 style lambdas, or proper haskell function definitions is irrelevant if you don't understand the concepts.

No, the comment replied to has the first four words "Might be cool to". The differences are so minuscule that the argument could be made for it to be 2 differing standards for the same language.

What you're describing is the exact same, just different syntax.

I'm not a python developer by trade, but there isn't anything wrong with pep8 standards. Standards are good, they remove ambiguity and make the code uniform. You shouldn't have to write a thesis of comments to describe what can be done with variable names. The project is taking longer because you are fighting a _standard_ opposed to working with it - swallow your pride and work as a team.

How to deal with management breathing down mandates wasn't the question. The 'company' in this context represents you and your team.

Is moving away from the bay area out of the question?

Have the same issue, it looks like someone deleted their entire site, or at least unlinked it.

This approach is so far from reality it hurts. What are you learning in 15 minutes that can inform you enough to make a decision to hire someone for a minimum of 90 days? Not enough.

You're missing out on other aspects of hiring like recruiter fees. If I were to hire every idiot that ticked off the boxes but couldn't demonstrate relate knowledge to something tangible I would've put my current and previous company out of business.

Your 90-day long interview process (this is what it is, face it) is not only a financial detriment, but a productivity tumor. Yes, I do agree that the current wide-spread use of "solve this on a whiteboard", "implement merge-sort", or some other backwards method of technical ability does not work; that is why I implement questions, and paired exercises that are tailored to the position they will be filling and the background they're coming from. The process I have in place consists of 3-parts: phone screen, and 2 in-person interviews - this process normally doesn't extend past 3 hours. The interviews are structured as a conversation to make sure the most nervous of interviewees can perform comfortably. I'd rather waste 2 hours more per candidate opposed to ~20-40k GBP for a poor trial, and a decrease in overall team velocity.

Breaks after the first input is submitted. Won't let you type further.

Wether it is easier to read or not is entirely subjective. There is no quantifiable measure to state either way. Both have their use-case; one now more than the other.

On OSX Vagrant always had issues with rsync of files. If you're using vagrant as just a blank machine, there is no difference between a blank debian/jessie docker image - apart from the lower resource usage. If you're not orchestrating anything concrete onto that vagrant box, I feel a proper workflow would be of benefit, i.e. properly reproducible builds. Take all those manual commands, prefix them with RUN in a docker file, done.

There is a mention of the taxi association being a major opponent. The black cabs have had numerous strikes regarding uber for their own wrong doing, it just seems like another tirade from them. There was legislation passed that required all black cabs to hold card readers, the overwhelming majority refused to allow you to use them, install them, or acknowledge the legislation ~2 years after the fact. They only have themselves to blame.

At a point in the past black cabs used to be good, this is no longer true. Not having uber (or an alternative - black cabs are not) will be more a problem than most realize.

You hit the nail on the head. The biggest save for well structured teams would have to be revisiting tickets/speed of development. Having a compiler tell you: this field is missing, this field is wrong, a cannot be b saves a ton of time in terms of development validation (manual or automated).

Can't use the electron app anymore b/c it'll consume all memory available on my development machine - I have 16gb worth. It's not consistent in memory consumption either, random times it'll get hungry. The connectivity thing (on debian based linux at least) is a major issue for me; it'll never resync after reconnecting to the internet. Only solution is to turn it off and on again.

Would be good to be able to kickstart the process via a query string, i.e. varvy.com?q=https://my.url

It all depends on the team, but personally the larger the team gets and the more complex your application becomes (monolith/microservice/etc independent) types are invaluable when it comes to shipping an actual product. You gain speed increases due to paths being evaluated ahead of time (compile time), but these are all secondary to developer peace-of-mind and time saved when work actually needs to get done - this includes ticket revisits due to "oh I forgot about that case", or "user did x and now this object is a string".

Yes, you should write unit tests to cover this in interpreted languages with weak or no types, but this depends on the developer a) doing it, and b) not missing any cases - PRs/code reviews are not a catch-all. Especially in the case of factoring common logic out or some other form of refactoring, a strongly typed language is my best friend.

More often than I should, probably. (https://wiki.haskell.org/Lifting)

For Haskell, Atom is near unusable. Input lag reaches double digit seconds, and crashes are frequent. Sublime is a tad better, but background processes for both are not managed well. Base editor vs editor, Sublime is the clear winner for general editing (not dependent on background processes/hooks) in terms of performance mainly due to io cycle time - mostly electrons' fault.

Vim and emacs are the solution most of my colleagues use, my experience with bindings in those editors is poor, but I'm switching slowly.

The biggest player using Haskell would be Google.

I can't speak on behalf of the culture in Singapore, but a lot of more corporate countries (e.g. Australia) will want specific experience relating to the role and will bias their decision on X years in the industry - some of your knowledge and personal projects will translate but i doubt you'll have the foundations a lot of juniors will have received during their time. I don't know your specific circumstances but from personal opinion i wouldn't hire you as a senior without having experience tutoring junior developers, debugging others' code, understanding drawbacks of certain architecture decisions and (possibly) being a slow starter.

In terms of age, most newer companies (mine included - London) don't associate title to time served or your actual age, but your abilities. We've hired a junior who was then 29 and made a switch from being an accountant. He had the gist of how things worked and his personal projects looked promising. He completed the coding exercise in a language he was not familiar which demonstrated well his ability to problem solve; guidance was needed but he was were we'd expect a junior with no comp sci background to be. I myself am the youngest in our team by quite a margin (mid-20s) and am the Technical Lead - age isn't a worry. Just be prepared to be outdone/tutored by people young enough to be your children; at previous companies I've met people that have fought me on every aspect bc of that fact even though i was brought in to advise and fix their architecture issues.