At least for me, webapps are just 1 in a thousand tabs open in 500 browser windows (ok, I exaggerate a bit). For an app with it's own window I can just hit a shortcut and said app gets focus. Disclaimer, not an Elektron fan.
HN user
fedesilva
twitter.com/fedesilva
[ my public key: https://keybase.io/fedesilva; my proof: https://keybase.io/fedesilva/sigs/fGJQ7Su1oBrrOqgigvaAEztUdAnr_pdC1TI-14bECX4 ]
About 6k+ people use it in my org - the vast majority are not devs.
Many people cross the Atlantic every year in relatively (not like this) small boats every year. There are common procedures and knowledge available to people that do that, see here for example: http://www.yachtingmonthly.com/archive/arc-safety-checklist-...
Examples of gross negligence: being dismasted in low or moderate wind conditions because lack of maintenance to the rigging and/or motor failing because of lack of a fuel filtering system, departing when conditions are obviously not favorable (wind against current in the Gulf Stream off the US coast).
There is no such thing as a clear line but it can be established for each case I think.
The lazy approach is probably way cheaper. Unless the social media shit storm is too big in which case they can correct after the fact.
Not saying it is ok to do it. Just that business will always pick the cheapest option they can get away with - that is, that does not affect the bottom line.
In my case its the contrary; it's the changes in patterns that distract me; the brain can move repetitive sounds to the background.
I don't play the same song but play repetitive music, also I use mid-tempo and up so I don't get sleepy.
"Knowing LinkedIn is saying "enough" is a real breather for me. At this point, I can stop. Hopefully it will trigger a chain reaction, and leave Scala for the academics."
You later speak of "hate" while justifying on the decision of one company your dismissal of a whole ecosystem. The chain reaction comment was tasteless and in no way looks like an opinion trying to make the platform better as a community.
If you don't like it, drop it.
Also FWIW in my experience with academics, most of them use Python, go figure.
-- EDIT
I don't usually reply to comments like this one but this time I could not resist. Sorry.
I would say that is because neither you nor the original authors had an idea of how things work (thread scheduling, etc).
Good for you if you rewrote it and it did solve your problems. Obviously it was not such a huge task, if it was, learning how to control those things would have been wiser.
In this specific case 'dispatchers' is what you were looking for (http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html) and it is quite flexible.
But this applies to any javascript program (or compiled to javascript). If you have specific requirements then scala.js is not the tool. Scala is.
I agree with you. There is a difference between simple and simplistic. Easy is not always simple.
It's true what you say about libraries and turtles. Still it's rare the event when I get an NPE from my/our code.
Sometimes think I would love to have a layer between us and Java. Some sort of FFI which returned everything on an Option.
Probably too cumbersome, but still ...
You can always use Option() as in:
scala> Option(System.getProperty("kaboom"))
res1: Option[String] = None
then map, getOrElse or fold at will.
(edited format)
In my experience most people won't even learn the ins and outs of the "for those who can't" languages. Worst yet, it's not about the language: most people won't grasp more important concepts that maybe "for those who can" languages force them to know upfront. And clearly while not knowing upfront some things is easier in the short term, it is a recipe for disaster as problems get more complex. So maybe it's about problems "for those who can" and "for those who can't".
Open source does not mean "Accept All Patches At All Costs", it does not even mean accept any patch at all.
My experience tends to be that distro packaged software is not always what one ends up using in production. Except for some base packages when you start doing more sophisticated deployments. Distros may backport bug fixes and specifically security fixes but they tend to be several versions behind.
Why did you have to write the same function again and again? I guess polymorphism would have helped, would it not? Not knowing too much c++ I can't really comment so I guess I am asking for a clarification.
I hear people saying this all the time. Why? For me they are similar to type-classes+records but without polymorphism. Care to elaborate?
No. It has polymorphism and metaprogramming, things that Go (at least parametric polymorphism) eschews.
If I understand correctly once you stop using the GC, Nimrod is not memory safe. Rust is.
There are several servlet containers listed, that is as plain as JEE can get, isn't it?
I wrote a simulation software to test a product in my previous job which used akka mostly but also used AHC which is a plain java http client library without problems. Size-wise the code would periodically get more features but by refactoring often it never got beyond 2500~3000 LOCs. Readability was never harmed; Scala - contrary to what some people think - allows for very clear code. People that inherited the code is working on adding features. Obfuscated code can be written in PHP if you want (or are unable to do otherwise). Another piece of scala software was an internal web service written using unfiltered on jetty. It's so stable sometimes I just forget it's there.
Curiously, I find easier to read the scala code than the commented pseudo code. I've been experiencing this a lot lately. It' seems I am loosing my ability to reason about code that loops explicitly.
One minor nitpick that can be of help when dealing with tuples: A partial function ( {case xxx => yyy} ) is a Function1 so you can use it with map and filter. This way you can deconstruct tuples into names and avoid using _1, _2, etc. { case (name, value) => blah }
https://github.com/MojoJolo/textteaser/blob/master/src/main/... could be made more readable by giving names to the tuple elements.
Thanks for publishing this code. It yields impressive results.
[Disregard, I read your post again after a coffee and in a normal screen. Sorry]
I don't understand "yet passing an object by value is only one character off from passing it by reference".
Is that Go?
"* Lack of parametric polymorphism means there's no useful higher-level functions like map, fold, etc."
This is one of my problems with Go, too. This will add line after line of repeated code in the long run. Time will tell.
"And if you screw up or forget to change it, your local modifications to the object are silently ignored. "
Since I started writing Scala I got used to immutable data and the reverse happens to me when coding in imperative style in other langs; that I pass something and it gets "locally modified" feels awkward. Preposterous even.
Regarding Go and the "also the anti-Java" part: I really don't think so.
They have made some decisions that seem to me a reaction to c++ and that at least is similar to Java. Some of them seem simplistic not simple: for example "There is no inheritance!" (one one one) but I really don't know how implicit structural subtyping will work out in the long run.
What I really envy from Go is the "compile and link to one executable" from an ops point of view.
Time will tell.
[Edited to add envy part, and rewrite a phrase]
When faced with a JS problem in a SPA - around 6 years ago - I had a representative from a client say me "wait, I will install the latest JAVA and see if that fixes it". He even chose the jdk to be safe.
I would put Percona higher in that list if you have the money.
Maybe it's old age but I find that annoying too. Looks pretty but is unreadable.
I always assume undefined is wrong.
Interesting, I never had this happening to me, and I have not tested your example, but I'm bookmarking this to try some time later. Can you confirm this is a problem with sbt 0.13?
Thanks for taking the time to make and example.
Correct.