runT1ME

I think there is nothing wrong with asking a candidate to do live coding/algorithms given that they could be solved in reasonable amounts of time and the interviewer has practice in helping a candidate feel comfortable doing so.

If I'm in an interview and I feel judged/nervous enough I'm going to struggle to spell my own name, much less write a merge sort. If I feel like I'm having fun and the interviewer is just sort of pair programming with me to make sure I'm not BSing that I could code, then sure, I can probably do most medium level algorithmic problems after some stumbling around and mis starts.

>In contrast, an engineer or computer scientist capable of working as an applied mathematician definitely requires an advance degree. I laugh when webdevs call themselves engineers.

Why would you think this? Do you think everyone who has a degree in CS understands algorithms, compilers, type theory, PL design, or operating systems at a deep level?

Why would it be impossible for a self taught dev to learn these things? I've been in the industry for over twelve years and have found no correlation between degrees and deep understanding of CS concepts. Some with degrees have it, some without... shrug

>OOP is very powerful to organize the architecture of your code and capture very common patterns such as reusing an existing piece of five functionalities while overriding one (something that's still awful to achieve in FP, regardless of the language you pick).

This is not true, ad hoc polymorphism works fine without subtype polymorphism.

Docker.

One, salary is not total compensation. Two, if an H1B can job hop, you have to include a nice carrot along with the sponsorship to keep them around (vesting RSU, vesting profit share %, tiered bonuses etc). Let the free market work.

I like Ceylon a lot, and I think the creator has done an awesome job taking community feedback and integrating it into his vision. It's one of the few languages I'd be happy to work in day in and day out.

It doesn't really compete with Kotlin with being a barely better java. I don't think Kotlin really adds all that much compared to Java but it's stupid simple to learn so I can see some teams transitioning to it.

Scala on the other hand is not easy to learn, but very powerful and can be written as a fully functional language. It's awesome, it has some warts, but at this point it has so much momentum that people who want type system power + FP on the JVM are going to choose Scala. It has the libraries, it has a plethora of big companies using it, and it has plenty of jobs (check the HN hiring posts even).

Ceylon definitely improves a bit on Scala, but maybe not enough. That being said, I like seeing other 'powerful' languages thrive, so hopefully it will pick up a bit more adoption. Alternatively, Gavin and the team will just decide to help out the scala compiler development ;-)

This is such a weird reply. If you are talking about where you'd rather live, then it makes sense to talk about all things given you like your choice.

However, that's not the discussion. Wouldn't it be more productive to say "how were american engineers able to get so well paid, and how can we emulate that in Europe?"

    I feel like the industry treats software development as a race to the bottom

Why have programming salaries skyrocketed the last five years then???

If a small business needs lower salaries to thrive, then that means their only real benefit they provide their customers is the fact that they can exploit some employees ignorance of market rate.

Think how many developers you could add by adding Higher Kinded Types to F#. You could poach a ton from Scala/Haskell land. Alas, many of us can't leave until that happens. :)

> Now all you have to do is make an un-encrypted connection to any site, and they've got you.

Seems easy to ensure that doesn't happen. If I block all non SSL requests going out from my machine, what's the next step?

I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an application. If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time.

Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it can feel like a waste of time.

I think you hit on part of it which is that for a while Scala sold itself as a better java, and people ate that up, until they found out it wasn't.

Scala is not a better java, in fact it's a worse java (with better type inference). It has a worse IDE situation, compile times are slower, and it takes much longer to master.

Scala has been and continues to be my favorite language though, and I would absolutely use it for new projects along with building a company off of it if given the opportunity.

Scala's strength is not as a better java, but as a full fledged functional programming language that allows you to write pure, easily testable, easily parallelizable, robust software.

Rob Pike's statement is a reflection of the terrible mistake he makes by conflating application complexity with statement complexity. Any given line of Scala can absolutely be more terse and difficult to parse than a line of Go or C or Java, but that is often inversely proportional to the complexity of the entire application. Powerful languages mean less need for frameworks and less need for reinventing the same thing over and over. See Go/Generics for a microcosm of this idea.

     Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.

 

I don't agree. I work on an incredibly large Scala team and a powerful type system gives you a lot more confidence to make everything from minor bug fixes to sweeping refactors.

The price paid for having to learn the complexities and power of Scala (which I'll admit is much harder than other languages) pays off in that it lowers the overall application complexity by reducing the need for a plethora of frameworks/libraries.

If you write Scala like you'd write a java/python/Go application, you'll have better type inference and a worse IDE, along with slower compile times. Not a great proposition. If you write Scala like a pure functional language that allows you to create powerful libraries and DSLs that make it possible to hack together very reliable applications, you'll be amazed.

But I'm saying, if you have a Higher Kinded Type like Strong, what do you name the variables? They don't refer to actual nouns. We're abstracted from that level.

What do you mean "document the types". They're type parameters... can you suggest better names for the parameters in StrongSyntax?

    It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala

Huh. Yeah, sounds like Go is a really good choice for you guys! For some reason our team is able to onboard new engineers and have them be productive in less than a month...

I have a comfy lounge chair in my living room. It's very different than sitting in a desk, so it's a good ritual for 'play time' coding. I'll crank the music a bit louder, have tea or whiskey in the evening, and try to work on things that are interesting and don't have a deadline (usually open source work, though not always).

This seems to be enough of a change of pace that it's relaxing. Now, sometimes it just doesn't work. The nights I'm feeling particularly burned out or not in the mood I'll just work out and then watch netflix.

I really wonder how much of it was timing. Startups with very little to lose aren't going to pay for support contracts on open source software. That takes established companies with SLAs, or quantified dollars lost per minute of downtime, or companies that just can't hire fast enough and too much work to do to bother with investigating DB issues.

But these companies that would pay aren't going to roll out new products on a database only a few folks have heard of.

Let's suppose in an alternate universe Slava had made Rethink his hobby project and it had taken ten years to get to where it is today. Even then, companies that had taken a gamble on it may still be a few years out from where the survivors can (and it would make economic sense to) buy a support contract, but their runway would have potentially carried them into the sweet spot of having early adopters become paying customers.

    Another programmer finds myObject.doExplicitThingToWorld() far more expressive and easy to understand

By definition, I can reason more about my function returning a monadic context than I can about theirs. I can get free theorems from my function, I can see clearly if I'm doing both input/output, (or just output), and I have laws to help me understand how I can compose this function with others. None of that comes for free when side effecting freely.

    in my experience either IO absorbs everything but the most trivial trinkets that I wouldn't ever mess up anyway

You mean you never mess up business logic? IO should only really be used when you need to be interacting with the world, IE, network calls, UI, etc.

    pure FP is just like pure OO

As someone who did OO for ten years and is doing FP full time, this statement is absurd.

    Why constraint ourselves?

You are not constrained in any way by FP, you just have to make everything explicit so programs are easier to read and reason about. There's nothing I can't do in a pure FP language.

    The world is not pure,

The world is not a touring machine either, does this argument have more substance or is it just an offhanded comment...?

    our programs don't become ANY better because of the IO monad

Do you actually have any experience with functional programming? Non rhetorical...it's such an odd thing to say.

Programs absolutely become better when you encapsulate IO in a monadic context. The entire point is to demarcate what functions interact with the world and which don't. This makes testing easier, reading code easier, composition easier. What functional language do you have experience with that would lead you to these bizzare conclusions? :)

I agree. I switched to working remotely for a Silicon Valley division of a major company, and I definitely feel the difference in appreciation. I'm not by any means treated as a special snowflake, but rather I very much feel it's a two way street, I feel lucky to work there, they feel lucky to have me.

This is in stark contrast to when I was consulting in LA/OC, where I was constantly having to justify my not so high hourly rates/fixed bid projects.

The Bay Area is about the only place I'd relocate to. I'm picky about what teams I'd want to work for, so the only way I'm going to upend my life, sell my house, buy a house (or find a place to rent) is if I know that I won't have to do it again if things don't work out.

I'd throw LA into the mix too, as it has a growing tech scene and a lot of things going for it. Seattle, Austin, and maybe Boulder if you can survive the cold.

The argument is more along the lines of "the upsides of Generics are known, and the downsides are that many of our users will find them confusing". That pretty much says what you need to know about the language.

>one of the reasons we could not switch to Scala was the steep learning curve which would be a big problem for new developers joining us

I think this is overblown. Yes, the language has a deep learning curve, but you're really trading off language complexity for lack of framework complexity. Because the language is so powerful, you'll see a lot less 'magic' frameworks (no need for a DI framework, no need for AOP, etc) so applications tend to have a really low barrier of entry to work with. We hire new developers all the time and they are productive way before they master the language.

> A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas."

I think this is a pretty big myth that only applies to some of these language features.

I've gotten to a point where doing Open Source can be a way to relax. Some nights I'll put on some good music I can code to, have tea or a scotch, and tinker around without the pressure of getting something done on any particular timeline.

> The key difference is whether the candidate truly understands the mathematical and statistical basis of machine learning

Can you elaborate on this, and at what level? Are you talking about a PhD level of understanding of cutting edge mathematics, or do you mean understand the basics, or somewhere in between?

Thanks for replying, yeah I suppose I didn't think about the ramifications of having to deal with reified generics and higher kinded types. I still think they're an amazing productivity boost, and the initial 'weirdness' of learning that particular abstraction pays off a tremendous amount in code readability.

As for the 'cool paper' comment, I wasn't aware of this new jargon, thanks for informing heh. I'm not sure how well it will play outside of haskell, I've done a Scala encoding of them and it's a bit more awkward than other representations.