What "better java" means? It means I can build the same stuff but in a better way. Easier to read, to maintain, and at least with the same performance.
Scala has a big plus on asynchronicity, but the article doesn't even try to go there. Libraries like Akka, FS2, Monix, ScalaZ etc are not mentioned either.
In Scala I can use everything from Java and much more, and this is why is better.
I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.
A "better Java" means keeping the same concepts and paradigms as Java, but fixing some of the design issues. That's what Kotlin is.
Scala on the other hand is a completely different beast, but some people use is as "a better Java" because it doesn't force you into its paradigms. You can code in Scala without using case class, with var everywhere, etc.
It can be handy to fallback to "Java style" when you don't know how to do it in idiomatic Scala, but at the end of the day if you don't want to embrace the key paradigms of Scala it's better to use a different language.
> In Scala I can use everything from Java and much more, and this is why is better.
You can use everything but it's not always very nice. For instance one of my biggest source of frustration is dealing with XML and SOAP (yes I know...) Scalaxb is good but limited, and using Java libraries means dealing with Java POJOs. I can definitely see Kotlin's potential in the "perfect Java interop" space.
That said, I agree with you, and I enjoy those high-level libraries too much to switch back to a less powerful language.
One should imagine the days without computers... waiting days for a letter to arrive...
Even if you don't like computers many of the benefits that come with them you might like... so think of them as a necessary evil.
IMHO the “Singularity” will be achieved when AI will invent new things. We have only reached the point where AI can only do improvements of something humans have created...
Innovation is something hard for humans, so I don't know if we will see AI innovations anytime soon.
I think your standard needs some work. Humans also only improve something other humans have created. And in niche applications AIs already outperform humans.
Nice article, but I can't agree with everything inside.
1. Engineers are not computers, so saving 5 minutes a day will not increase productivity by 1%. Most engineers work with passion, and don't look at the clock. They are focused on delivering a certain task, and they will make their best to deliver it, even with the interruptions, even if this will require them to work 10 minutes more at the end of the day.
2. The benefit of the tools is a clear win, but as these tools will not change so much over time, after the initial boost of productivity, the effect will no longer be noticeable. You can't increase performance each month compared to the last month just by using the right tools. So I think the EE team make sense to be created "on demand" and not as a permanent solution. Time should be a parameter in the effectiveness model
3. If you grow to a large scale enterprise, as the people are not computers and reaching agreement between large number of individuals is not easy, the bigger the number of people in the EE team the harder will be to approach solutions and test them.
> they will make their best to deliver it, even with the interruptions, even if this will require them to work 10 minutes more at the end of the day.
I'd say giving your engineers 10 minutes more free time at the end of the day will give long-term returns too. Engineers are not computers, they need time to unwind after work like everyone else.
As organizations grow, it can also become harder to maintain the passion you mention. This is a huge factor that people usually don't account for in their models.
after the initial boost of productivity, the effect will
no longer be noticeable
But the purpose of the team isn't just to get the initial boost but also to prevent a continual loss of productivity as the tooling inevitably bitrots. When you hit a certain size that bitrot happens much faster than you might think. It makes sense to keep an EE team on just to do maintenance. And support future changes to workflow. New languages and frameworks. Large scale refactorings happen more and more frequently as you hit walls that weren't there a month ago.
Argument #1 does not really make sense, since by repeatedly applying the same logic it implies that engineers will work an infinite number of minutes each day. A variant of this argument that I've often heard is this:
"My decision to take the plane does not negatively impact the environment, since the plane would fly with or without me in it."
The point I was trying to make is that for engineers you can't do a simple math from minutes to productivity. The interruptions are big productivity killers, but all engineers take voluntary breaks. A break helps productivity, but there is a limit, above that it harms. The same with the interruptions, some might help, too many will not.
A break the engineer chooses is chosen and is unlikely to interrupt flow. An interruption caused by the tooling is not chosen and is more likely to interrupt flow.
Tooling cruft also increases the startup cost of some tasks. Where the amount of pain you will experience trying to do it may inhibit your desire to dig in.
The author was generalizing he wasn't assuming perfect accuracy. But in an engineering organization the size of Twitter the productivity gains of a dedicated tooling team add up fast. Much faster than you might think.
I could see people seriously agreeing with the plane argument.
I think to spin it even worse, replace it with some sort of group crime. I joined the riot, because there would be a riot with or without me. I join the drive by shooting, because there would be a drive by shooting with or without me.
I think that would have less people agreeing with it than the plane argument.
> I think the EE team make sense to be created "on demand" and not as a permanent solution
For the size and intensity of effort going on at Twitter, I respectfully disagree.
Once the team gets large enough, NMP ("Not My Problem" mindset) comes into play, and unless you have the culture from the beginning to always be making the development process better, and acquisitions and new management has never changed that, which is highly unlikely, then having a dedicated person or team to help make other developers jobs easier is a great idea- after the team gets to a certain size. What that size is depends on what is being done, though.
> Most engineers work with passion, and don't look at the clock. They are focused on delivering a certain task, and they will make their best to deliver it, even with the interruptions, even if this will require them to work 10 minutes more at the end of the day.
Right...
First, IME engineers aren't any more passionate about their jobs than anybody else. Even for people who are passionate, the majority of their day is unlikely to be 100% dedicated to the things they're passionate about. Nobody I've ever met is passionate about digging through their inbox in the morning, or going to scrum meetings, or doing sprint planning, etc.
Second, engineers are also the ones who get most upset and demotivated by the pointless waste of time. If you can speed up my compile by 5 minutes, then do it. If you can speed it up by 5 seconds, then do it. There's nothing the engineers I know hate more than wasting time on tasks that could be automated or made to run faster.
I think the team could very well exist permanently. It's just that their aim would then not be to unify tools, but to ensure code quality and work efficiency of various teams, as the author already stated in the article. Quality assurance and checking can be beneficial all along the way, as long as it's not overdone.
I think the AI should do more than just correlate some verbs. It should also be capable of understanding concepts like. If I give the following:
"John and I are brothers. My mother has a brother named James. "
And we ask:
"What is the name of my uncle?"
The initial results are great but in my humble opinion the big quest is to make computer learn concepts.
You obviously sound like you're interested! Why not fork the repo, contribute? :) It's a great demo project, and I love seeing these on HN.
OP - Instead of linking directly to en/Stanford Parser etc, you should get together a list of dependencies people need to run your application. Usually as easy as 'pip install pattern' (for the 'ImportError: No module named en') which is `import pattern.en` :-)
I like it! It's nearly 2am so better catch some sleep, but I'm definitely going to have a look further tomorrow.
> It's a great demo project, and I love seeing these on HN.
Thanks!
> OP - Instead of linking directly to en/Stanford Parser etc, you should get together a list of dependencies people need to run your application. Usually as easy as 'pip install pattern' (for the 'ImportError: No module named en') which is `import pattern.en` :-)
I didn't actually pip install anything for my project, I just downloaded and extracted the Stanford Parser, and Nodebox Linguistics libraries. The setup should be in the readme. I'll try to see if I can find the pip dependencies and update the readme.
If a human looks it would be trivial for me to do the legwork to prove I own the google account.
I've had more than one job that uses gmail in the office, including my current one. My boss's account is presumably authenticated and if I bugged him he would vouch for my identity.
I have correspondence with a bunch of people in my google account going back years. I could bug any number of them to vouch for me.
I've had, in the past, a few work accounts that used google, that mad my picture associated with it. I can do a google hangout to show that that is still my face.
I have a driver's license with my real name on it, which matches my google account.
I control the phone number associated with my google account.
. . . A hacker could compromise one or two of those, but it would be hard for him to get a majority of them, even if he had my phone and email in his control.
I wish people would accept drone world wide. Unfortunately in many places they are forbidden :( This is sad, because if tomorrow someone would invent a flying car, something like the taxi from "The Fifth Element", then most probably that will be forbidden as well, on the same principles.
"It is impossible to make imperative programming languages safer by only partially removing implicit side effects" So when we can call a program safe? My personal definition is that a program is safe when it always gives the right output for the input it was designed for. Of course if you put water in your car won't make it run, the same way if you provide the wrong input to a program might end up in a wrong output. Getting back I do believe in the middle way.
I like the idea, but can I suggested also on the same note that they can create a high tech condom, which will let you know how many diseases you have avoided each time you wear it, and it might have also a pleasure indicator, so at the end both partners, will know how much the other one faked. (Obviously this message is intended as a joke, and should not offend anyone)
You've just painted a horrifically realistic concept for the quantified self crowd. How was my orgasm? Was it better or worse than the one I had two days ago? Is my current partner giving me better orgasms than my previous one? Let's upload all of this personal data to the cloud and get some pretty charts...
There are already litmus-style tests kicking around that change colour in the presence of a disease or virus. Maybe in future all condoms will warn about STDs... although you could imagine that getting depressing if you have an incurable one.
I'm sure by tomorrow someone with more time than I have will write an extensive article explaining in more detail why is better.