Google now knows when its users go to the store and buy stuff (2017) - <AUTHOR> https://www.washingtonpost.com/news/the-switch/wp/2017/05/23/google-now-knows-when-you-are-at-a-cash-register-and-how-much-you-are-spending <comment><USER2> Credit card transactions and location data do not prove ads are working. Google already knows where you shop long before you get served an ad. I keep getting ads to persue a masters in CS which is somthing i have been planning to do anyways. Furthermore i make it a point to avoid stores that were advertised.</comment>


'Android' Is Over – Normals Call It 'Galaxy' - <AUTHOR> http://www.businessinsider.com/android-is-over--normals-call-it-galaxy-2013-2

<comment><USER2> ... and its about time! "Android" has somewhat sinister connotations. Motorola ran with the concept in their marketing of their "droid" phones and it looks like something from the movie Alien, probably not the best strategy to entice half the population: females.</comment>


T.rex 'little cousin' discovered - <AUTHOR> http://news.bbc.co.uk/2/hi/science/nature/8405897.stm <comment><USER2> The neat thing about this discovery is that it's the discovery of a new species, older than the infamous T-Rex.

Another (slightly more detailed) article: [http://www.deseretnews.com/article/print/705350658/Dinosaur-...](http://www.deseretnews.com/article/print/705350658/Dinosaur- discovery-sheds-light-on-Triassic-University-of-Utah-scientist-says.html)

"Little cousin" from the bbc headline is probably an inaccurate description of the _Tawa Hallae_ . . . more like 15 million year-old ancestor of the T-Rex.</comment>


The Tyranny of Process Worship Within IT - <AUTHOR> http://www.ciopedia.com/u/27

<comment><USER2> I think a distinction needs to be made between actual process and codified process. The former always exists, and the only question is whether it is working or not. The latter is endemic to large organizations with disaffected and mediocre management and employees, which is what Netflix is actively fighting against.

However the tone of this piece and the original Netflix manifesto does not acknowledge this distinction. I think this shows a bias that is driven by product-oriented software engineers and creatives. "If the product is great then who cares how we got there?" Well that's certainly a valid viewpoint, however it shortchanges great management. Great management is not done by simply hiring the best people and turning them loose on a project. That works in a startup where everyone knows each other and so any two people can notify each other of relevant issues. It doesn't work in larger organizations where individuals have a much narrower slice of responsibility and thus lower visibility on the whole actual process going on.

I've worked with some people who take a process-oriented approach and were very talented at getting the best work out of their employees. For these people it's no more about rigid codified processes than it is about a relentless focus on product. Instead, the goal is to understand at a high level what all the various stakeholders are doing, where their individual bottlenecks are, and determining a process that maximizes everyone's productivity. People like this are incredibly valuable, because let's face it, management is much harder than programming to do well because you are not a domain expert in anything, instead you have to figure out how to help all the different domain experts operate efficiently.

I realize none of this is news to the folks at Netflix, but I think the way the manifesto is written de-emphasizes these facts to the point that the inexperienced or low-level programmer may miss the forest for the trees, which incidentally is exactly what the problem with bad actual process is.

<comment><AUTHOR> Thanks for the comments. I should have made a better distinction between actual and codified process. My thoughts were toward codified, which, as you state, are endemic in larger organizations, and seem to build on themselves over the years, good and bad, until less and less actual progress toward the ultimate goals of the organization is accomplished. Process is delivered, rather than products...

Although I did not agree with everything in the Netflix deck, I was impressed by the "bias" toward great people rather than great process, which seems to me, to be a fresh take on it. There will always be necessary processes and there are certainly many great process best practices to draw from, but I do think we should all be CONSTANTLY QUESTIONING what is in place, asking ourselves if it is serving us or we serving it, and making changes as needed. It is my experience that this happens rarely in large organizations. There simply isn't the political will to take it on...

<comment><USER2> In the corporate world it's _definitely_ a fresh take, and that alone is worth a lot.

</comment></comment></comment><comment><USER3> The problem here is that everybody thinks that they're talented superstars, and they don't need to have to worry about rolling back a version, or testing, or any of those other dreaded bits of 'process'. Which is another way of saying, "putting some steps in place to cope when you inevitably screw up."

This piece sounds like it's written by some cowboy who wants to move fast, and be all agile and light. These people are also nominally nowhere to be found at 4am when their undocumented change brings down the production server farm, and then I have to get up and fix it... which is all kinds of fun.

The fundamental problem is that most shops are organized with 'IT', 'Operations', and 'Development' all being very separate camps. There's no mutual respect, and plenty of blame, so massive piles of process get created as a means of defense for the Ops and IT guys, who get screamed at every time there's a problem that hits the customers.

There's a really good talk on why this is bad from the Velocity conference, here: <http://velocityconference.blip.tv/file/2284377>

<comment><AUTHOR> Thanks for the comment. no, I'm actually not even talking about the process of building software, (as I stated in the post), and am anything but a "cowboy". I'm talking about all the dozens of other processes that add zero value to the product, that are put in place with the best of intentions, and add all kinds of cost....things like spending 30 minutes a day tracking time for every meeting attended against an activity/project, multiple processes taking weeks for acquiring a server, weeks spent in generating documents that are not even looked at by others, etc... hopefully that makes sense.

</comment></comment><comment><USER4> There is only one process in IT which I worship:

      USER      PID     COMMAND
      root      1       /sbin/init

<comment><AUTHOR> excellent t-shirt idea

</comment></comment><comment><USER5> I think we need to create an approval process for processes so that we can slow down the creation of processes.

<comment><USER6> Was that comment approved????

</comment></comment><comment><USER7> "We should focus on what people get done, not how many hours or days are worked. Just as we don't have a 9-5 day policy, we don't need a vacation policy."

While I admire the sentiment, it's rather anti-family.

<comment><USER8> Can you elaborate?

<comment><USER7> That sort of policy encourages people to work very long hours to out-compete their coworkers. And don't tell me that there is no competition working for a place where adequate work is rewarded with a "generous severance package."

You pay for that sort of thing long term with burnt out employees and broken families.

Vacation and the 9 to 5 policy encourages people to compete with each other without going overboard and ruining their lives. Whether that's good or bad for you, their employer, is something that you need to consider.

<comment><USER8> We have a similar policy where I work. There are certainly people who work harder, or who take less vacation than they would like. But from what I've seen, most of these people are either workaholics, or underperformers who probably shouldn't be working here anyway. I suspect most of these people would be working long hours regardless of the work hours or vacation policy.

For the rest of us, the freedom is tremendously valuable, and we have fantastic work-life balance.

</comment></comment></comment></comment><comment><USER9> I voted this up immediately after reading the title.</comment>


LinkedIn EgoBait: Don't be Fooled - <AUTHOR> http://geekgirl.com.au/blog/2013/02/13/linkedin-egobait-fooled-geekgirl/

<comment><USER2> Agreed I get all sorts of linkbait scam for:

LinkedIn Facebook Google+ etc

usually tech support wants to talk to me or I won an award or have a friend request all fake phishing attempts that go to a different web site when clicked on than the one it pretends to be from.</comment>


Open Sourcing Active Question Reformulation with Reinforcement Learning - <AUTHOR> https://ai.googleblog.com/2018/10/open-sourcing-active-question.html <comment><USER2> I haven't read the paper yet — but from the summary the agent rewrites questions and learns to find "more rewarded" reformulations — but how does the environment derive a reward signal useful for observing the quality of a reformulation ...? That seems as hard as the original problem to me ...

<comment><USER3> I looked at the paper (too Fast I could say bullshit), the techniques consist of retrieving from a question a list of differently phrased same question thus, if the existing QA answer system fail with one, it can retry with other phrasing of the same request. Also they may combine answers from subquestions to the global visible answer, but this must have many issues.

Nothing directly reward reformulations. But the global answer can be rewarded by user feedback. Yes this indirection still seems like an issue.

What I would do instead of this strategy would be to cluster extremely similar/other formulations of the same question by different users and then store for each frequent common question a list of reformulations (user generated). Of course the list would be based on the profile of the user.

I do not answer How similarity/identicality of user formulations would be determined by I have a couple of heuristics in mind.</comment></comment>


Intel Has Tapped Samsung Foundries to Manufacture CPUs - <AUTHOR> https://wccftech.com/intel-has-tapped-samsung-foundries-to-manufacture-cpus/ <comment><USER2> Ouch, bet that was a difficult conversation within Intel.

One has to wonder, though, how long it will take Samsung to begin producing Intel processors at volume? Surely it can't be less than a year, meaning that Intel's supply woes will persist at least that long.</comment>


Why I like Clojure - <AUTHOR> http://sulami.github.io/posts/why-i-like-clojure/ <comment><USER2> My favorite thing about Clojure:

You compose libraries, instead of totally buy into framework A or B. Some people prefer the opposite.

However, Composition _works_ in Clojure because everyone is using the staples: functions, maps and seqs. Pretty much everything in the language can work as one (or all!) of them.

While I also like static types, this is my argument for a well designed dynanic language like Clojure or its Lisp relatives: stuff just snaps together like magic lego bricks.

<comment><USER3> Composing libraries instead of buying into a framework is a wonderful thing. It allows a developer to use just the parts they want, integrate them with just what the developer needs, and get on with whatever they're doing. It's a beautiful idea, and it can enable amazing levels of productivity.

With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the ecosystem incredibly immature. It's somewhere beyond arrogant - reckless comes to mind - for most engineers to do all their own plumbing for a web service. The odds that they'll manage to design someone easily long-term maintainable are slim. The chances of authorization, authentication, potential SQL injection, and a thousand other security things being handled well is effectively none - the Clojure ecosystem often seems wildly ignorant of such things. The core philosophy of just composing the libraries you need with Ring means that anything you don't actively think of will be likely entirely neglected. This is a dangerous way to ship code that will be facing the real internet. Clojure requires you to fit absolutely every aspect of everything you're doing into your head and be handled by you, because nothing is going to do it for you. The lovely magical LEGO feeling is, sadly, a lie.

This stands in stark contrast to the level of consideration around maintenance and security that has gone into a modern, mature framework. Or a modern language where SAST is an option.

Doing low-level stuff feels _absolutely amazing_! The sense of control, of having your hands in the guts and the ability to do what you need without wasting time on bullshit magic, is heady and glorious. It's just perhaps worth considering that that magic can sometimes be incredibly valuable, well worth the tradeoff against the feeling of freedom.

<comment><USER4> Really though, Clojure web apps are at the php-no-framework level security days, not joking.

The most used HTML templater(hiccup) doesn't do any secure output escaping, bad password/session management, auth*, sql injection, bad encryption methods, its all there.

<comment><USER5> Hiccup has functionality to perform escaping with `h`. It doesn't do it by default though, for performance reasons and nesting of Hiccup in Hiccup. Normally, you'd just want to sanitize right before returning your response.

Doing it that way you can also perform more selective sanitation if needed.

Hiccup2 does sanitation by default, still in beta though.

The common SQL lib is java.jdbc or next.jdbc and they use prepared statements by default. Can you explain more where you see common risks for SQL injections?

I'm not sure what you mean by bad password and session management? Normally, the common lib people use is ring-defaults [https://github.com/ring- clojure/ring-defaults](https://github.com/ring-clojure/ring-defaults) what about these do you feel are insufficient? Maybe do a pull request about it.

Auth and encryption I agree, but the untold reason is that people just use Java bountycastle and Apache Shiro or other for that. Buddy is the most popular Clojure one [https://github.com/funcool/buddy](https://github.com/funcool/buddy) , but honestly, for that stuff, you want something super battle tested, that means popular, and Clojure as a whole isn't popular enough for that, so really just pull in a Java lib done, it works flawlessly within Clojure.

<comment><USER3> > Hiccup has functionality to perform escaping with `h`. It doesn't do it by > default though, for performance reasons and nesting of Hiccup in Hiccup. > Normally, you'd just want to sanitize right before returning your response.

One of the things that Rails' templates gets completely right is that it knows when something is nested and when it's going to be returned immediately. It is thus able to do its automatic escaping right before returning a response and not before.

At this point in history, I think this is the baseline behavior all templating systems should meet. Requiring users to remember to manually escape every output every time is begging for exploitation. Such a design error only strengthens the case that hiccup is not appropriate for serious use at this time.

<comment><USER5> It seems Rails used to default to not escaping as well, but in Rails 3 they switched to escape by default. And from what I'm reading, nested helpers do suffer from the over escaping, and in fact they warn not to blindly html_safe them. But I admit, I can't find very new guides on latest versions, are you saying ERB now tracks nesting and only escape once at the end?

That's actually what hiccup2 does as well by the way. I admit, it is a nicer behavior, and I'm not sure why hiccup2 hasn't gained more traction since it released, but you are free to use it, it's part of the normal hiccup release, just require hiccup2 instead of hiccup.

But hiccup is not the only popular Clojure HTML templating lib. Selmer, Clostache and Stencil which are much more ERB or Django like, both HTML escape by default.

</comment></comment></comment></comment></comment></comment><comment><USER6> I love the language. I've never found a language where I found the learning curve so shallow for being able to do so much.

That said, I do find myself pining for the ability to easily compile a static executable (maybe with a small embedded runtime). Some time ago there was an attempt to port Clojure to Gambit Scheme, but that appears to have fizzled.

More recently, I've seen Ferret, which compiles a subset of Clojure down to C++. Also Joker, which is a Clojure-ish interpreter in Go.

Then there's GraalVM, which I don't trust, because it's Oracle.

I feel like the relative lack of traction for non-Java / non-Javascript implementations is part of the brilliance and sadness of Clojure. Namely, the JVM is a rocket ship and a boat anchor.

Racket (modulo the uncertainty cast by the Racket2 discussions) and Gerbil Scheme both have a pretty good "distribute an executable" story while trying to introduce some creature comforts beyond plain Scheme. I suppose my ideal, would be something a little more like Clojure in terms of language, and a little more like Scheme in terms of deployment options.

<comment><USER7> Why not Chicken Scheme? It compiles down to C.

<comment><USER6> Oh, definitely Chicken as well. The library story with Chicken is also pretty decent.

</comment></comment></comment><comment><USER8> What I like most about Clojure is the interactivity: I can quickly test and iterate on ideas in my editor connected to a REPL. To me, this is the main advantage of Clojure.

Clojure's focus on the REPL, immutability and simple datastructures make it possible to inspect data and redefine functions in running systems.

In other languages I spend a lot of time making small edits, setting breakpoints, starting the debugger, waiting for the program to start, etc, where in Clojure I can just redefine and inspect stuff immediately, allowing very short feedback loops when programming.

A lot of Clojure tooling emphasizes short feedback loops: component with it's reload function to restart systems, figwheel/shadowclj with live reload of browser apps, which is a huge productivity boost.

Once I got used to the quick feedback loops that Clojure provides, all the other languages feel bulky and slow to develop in.

</comment><comment><USER9> > homoiconicity, meaning code can be represented as a data structure inside > the same language

> generating strings and passing them into eval like for example in Python

Python has become a pinata for language enthusiasts? Python lets you pin a decorator on a function, get the AST (a data structure AFAIK), manipulate it in a sane fashion in Python, compile it, return the result. No string munching eval require

I'm all for Lisp but this just isn't convincing

<comment><USER10> > get the AST (a data structure AFAIK), manipulate it in a sane fashion in > Python, compile it, return the result. No string munching eval require

I use both Lisps and Python, and especially after learning to use Lisps I've wanted to do this in Python, so I looked for the ability to do what you describe here.

While it is technically possible to do this (like most things) in Python, it is quite the effort and nowhere near ergonomic. Among all the cases where I could really use this, I found it worth the effort to instead:

1\. Manipulate & generate code statically (from ASTs), as a build-time / dev- time step, using redbaron etc.; or

2\. Just use a Lisp (specifically, Hy).

Both methods involved writing quite a lot of code. In the former: to load, parse, match, and transform ASTs; in the latter: to port existing code (the code I originally wanted to manipulate) from Python to Hy.

\----

The reason for all this is plainly the fact that Lisps are designed for this, while Python is not. Before learning Lisp, I used to wonder what could be so different in the language itself that could possibly make it that much easier. Now I use a Lisp-in-Python in production precisely because of this.

<comment><USER9> This is true, but I wanted to correct factual errors in the article.

If you or your team are Lisp users then Hy or Clojure would be good choices, but if you are just trying to create a transformation for existing Python codebases, the decorator approach is a good shoehorn.

On the other hand, you can also interpret the difficulty of AST transforms as a signal from the language designers (had van Rossum really never heard of Lisp?) that they hurt readability and their use should require a little ceremony.

<comment><USER10> I'm sorry, but I don't agree at all.

> if you are just trying to create a transformation for existing Python > codebases, the decorator approach is a good shoehorn.

For transformations that need to modify the code, decorators are insufficient. Decorators have their value, and I have built good interfaces using decorators, which would have been rather difficult without them, but all of that was because decorators help _wrap_, not _transform_ code.

When I had a need to transform code, I looked for the right tool, and the takeaways of my searches are mentioned in my original comment.

> you can also interpret the difficulty of AST transforms as a signal from the > language designers (had van Rossum really never heard of Lisp?) that they > hurt readability and their use should require a little ceremony.

Nobody's claiming Guido had never heard of Lisp, or any non-lispy-language designer for that matter. Language designers make languages for varied reasons. Guido's reasons actually happen to be documented, and the only reason Python isn't homoiconic is because Guido didn't have a need for it, not because he explicitly wanted AST transforms to "require a little ceremony".

In fact, Python AST transforms do not merely "require a little ceremony". They are actually quite cumbersome. The standard library actually provides no help at all in transforms, making it necessary for libraries like Rope, RedBaron, and Astor to be written.

</comment></comment></comment></comment><comment><USER3> I love the _idea_ of Clojure.

I find the ecosystem immature and full of ideas about "libraries, not frameworks" that leave developers incredibly vulnerable to their own ignorance and second-order ignorance. The number of developers I know - or even know of - that can be trusted to develop a useful and secure web application from the ground up with this kind of tooling approaches zero.

Clojure is a cool language. I can only hope the ecosystem soon matures enough to make it one that's suitable for serious use.

<comment><USER11> Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go.

Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and data parsing?

Technically rails is composed of a bunch of smaller gems with a similar responsibility tree although without the centralized CVE distribution and pressure that creates.

When I used Clojure it was always mini frameworks which created a base set of important packages with a pluggable middleware system on top and flexible data back ends.

The individual packages need to have domain experts for their particular attack surfaces and exposures.

If anything its about a lack of eyes or community size on the various wholes, rather than expecting the end user to do the individual hardening or plumbing.

<comment><USER3> You're right. Many things can be handled by packages, abstracting them away from the developer.

Of course, that's assuming the developer thinks far enough ahead to remember that they need authentication, decide how they want to handle it, figure out what they want for a CSP, and so on. Other things cannot be so readily handled. Authorization, for example, isn't a concern that can be bundled into a pre-fab function. It's something application-specific that has to be re- evaluated with every single web request and is going to be subject to unique business requirements.

Frameworks tend to handle these issues by setting out a set of conventions to adhere to, within which many of these concerns are handled for you to the extent possible. It's far from perfect, but it does a lot to reduce the chances of someone forgetting (for example) that forms need anti-CSRF tokens because their form-generation function doesn't do it for them or automatically work with the form-accepting and validating functions.

Or, to use example I've seen, the logging package's ignorance of what might be sensitive in the strings its been handed turns into secrets being sent to the centralized logging system and exposed to far more people than they should be. The developer didn't think about what might be in what they were logging, the package assumed that the developer _did_ , and the result could have been avoided by a more integrated whole.

A culture of libraries instead of frameworks can mean that each project may have to make all the decisions a framework does all over again. Is everyone going to get it right every time?

<comment><USER12> > The developer didn't think about what might be in what they were logging, > the package assumed that the developer did, and the result could have been > avoided by a more integrated whole

Umm, is there any all in one web framework that protects against this to any level of guarantee?

<comment><USER3> It's been my experience that Rails logging can and will do things like censor password fields when passed objects.

So, yes, it is possible for logging (and serialization) systems to defend against this kind of thing.

<comment><USER12> In my experience these password logging events tend to be at a lower level than object serialization. They're usually at the raw request level.

</comment></comment></comment></comment></comment></comment><comment><USER13> > While the primary platform is the JVM, superbly uncool but stable and > relatively performant

My impression was that java has the reputation of being "uncool" but JVM is highly regarded as modern marvel.

I am wrong about this ?

<comment><USER14> IT Java is uncool, but then IT is uncool even if written in Clojure (though the psychological aspect of using a "cool" language will likely dampen the existential pain of writing yet another book keeping CRUD app since now you are using s-expressions!)

In my experience, people who say silly things about Java -- the technology, which certainly includes the Java Language Semantics, and JVM -- actually do not know what you can do with Java (the language).

So yes, you Lisp nerds have you homoiconic 'mash' of syntax and thus AST manipulation, and we have first class Class Loaders and Byte Code Engineering and the sky is the limit there. Magic.

But the sad reality of programmers' lives is the disconnect between the required cognitive capabilities of workers and the actual (domain) task at hand.

tldr;/ its your job that is uncool not the tech.

<comment><USER15> > But the sad reality of programmers' lives is the disconnect between the > required cognitive capabilities of workers and the actual (domain) task at > hand.

Yeah, I just don't understand the less lines of code argument. This is not the limiting factor in software development, it's just not. The limiting factor is having enough information for the immediate Use Case and enough business domain knowledge to come up with a solution that delivers value to the business. The time spent on delivering that value dwarfs the time it takes to write some extra code. Let's look at Uncle Bob's example in the linked article...

(println (take 25 (map #(* % %) (range))))

While fancy, that code is very Perlish and I think we all know the common criticisms of Perl. Also, fancy doesn't pay.

What I've found to have a much larger negative impact on a project than the language is overly complicated architectures. To the extent Clojure can help with that I'm all for it. But from what I've seen, Java 8 with some clear conventions and constraining source code to the implementation of the Function interface can get you a lot of the same benefits.

</comment></comment></comment><comment><USER16> Clojure Help:

This is super apropos since I am JUST learning Clojure via the Clojure Koans.

Any tips from clojurists on getting the repl (and readline) working fluently? I'm using Leiningen but it's not responding as I'd expect. I would think this would all set up more effortlessly.

Tips on getting a new Clojure setup working would be appreciated.

<comment><USER17> I recommend emacs, try braveclojure.com - it's a pain to set up properly but well worth it.

<comment><USER18> As an avid Emacsen, I would usually recommend Clojure-mode and CIDER _only_ if you are already familiar with Emacs. Learning both - Clojure and Emacs can be really frustrating and may potentially become a "deal-breaking" impediment. Almost every [popular] editor/IDE today supports Clojure (not many mainstream langs can proudly say so)

</comment></comment></comment><comment><USER19> One (stupid?) thing that annoys me about closure is that native clojure libraries use snake case while java libraries use camel case. You could obviously write a new defn macro to take of all this and make it consistent, but it might have just been a better decision to just make everything camel case, in in Lisp-like fashion.

Also I find Clojure a little dogmatic in regards to mutation, more so than even Scheme. I find Racket to be better designed and more elegant, though currently the performance isn't as good.

<comment><USER20> Clojure being dogmatic is the reason I love it.

<comment><USER21> Agreed. While I don't always agree with its dogma, without it I don't think I'd still be using Clojure, yet here I am ten years after first learning it. Clojure is great _because_ it takes a strong stance on how certain things should be done.

<comment><USER20> yep. also, i think learning how clojure's dogmas synergize with each other is the determining factor in whether one is a clojurist for life or not.

</comment></comment></comment></comment><comment><USER22> > While OO seems to be out, and FP the new hotness

Funny that. While I prefer FP, and did since I've learned Python, my teachers are really hot about OO, even pushing us to use it in Python projects.

(Looking at projects from previous years, they mostly seemed to use Java. Then also because of browser integration and obviously because of the OO <-> UML <-> Project links ?)

<comment><USER23> Is there any reason to believe FP is the "new hotness". Each year in the Stack overflow language trends report the FP languages are barely making an impact.

<comment><USER24> FP languages are not that big. FP architecture and practices are very popular. React, Immutability and more have become mainstream.

A recent example is SwiftUI. While Swift is not a FP language, SwiftUI (FP UI framework) and Combine (a FP toolkit) is being pushed by Apple as the future UI architecture for all its OSes.

</comment></comment></comment><comment><USER25> Need someone to explain why I should use clojure over scala because typelevel seems pretty well developed

<comment><USER26> Clojure: live repl into running code

Scala:

Clojure: Explore the problem you are facing with quick prototyping in the repl and see the blind spots, the unknowns, the shape of data received from flaky integrations. Mold and shape your functions as the problem becomes clearer.

Scala: Best it can do is write unit tests and the debugger to look at what exactly is happening, devise a bunch of classes to handle them, rinse repeat and of course wait hours for recompiles. Refactor when new unknowns surface and curse at the fucking compiler not knowing what type it should be inferring.

Clojure programmers are done before Scala has a test environment up.

<comment><USER27> I'm sure you're happy with Clojure and I'm not going to try and convince you Scala is better but you have some misconceptions.

Firstly Scala does have a couple of REPL's, the best being Ammonite which is mentioned below. It can be embedded in code to provide a live repl just as your Clojure program. I often work in Scala in a similar way to I work in Clojure; creating and testing new types and functions in the repl before moving them back to a source file.

The way you build programs sounds quite horrible, but I know people do it that way and it works well enough. Your complaints about long compile times are largely irrelevant. Incremental compilation means it's usually 2-3 seconds at the most before I can test a change. We don't build programs as a bunch of classes by the way, that would be OOP. Scala is more commonly written in a functional and/or streaming/reactive stle. Also I'm glad you brought up refactoring. It's a breeze in Scala because of the strong type system. Poorly defined data can be expressed just well in Scala with types as it can in your blob of maps of maps, and it's much easier to work with.

Finally you may finish your program first; it appears to do the thing you want but you can't really be sure. There will be more runtime errors such as NPE's and type errors because you don't have mechanisms to remove them from possibility. I'd much rather maintain and evolve a Scala program.

<comment><USER28> > Scala is more commonly written in a functional and/or streaming/reactive > stle.

This is the exact opposite of my experience. All the Scala I've seen "in the wild" is basically Java with a slightly different syntax. All OO, with the odd high-level function thrown in to prove something I guess.

</comment></comment></comment></comment><comment><USER29> as i was talking to a friend about clojure i came up with an analogy i cant shake: clojure is what happens when you just make your programmer directly write an AST. a bit reductionist, but anyone care to debate this?

<comment><USER30> Isn't that the point of lisp and homoiconicity in general? That you're writing an AST that you can also treat as a data structure?

<comment><USER29> ok so... why is writing an AST more ergonomic than having some syntax?

<comment><USER30> It's really not. That's part of the problem with lisp. But you can treat your code as a data structure which offers a lot of benefits. For instance, it's basically impossible to offer control flow as a library in normal languages. That is, if you wanted to implement an unless statement like in Ruby, you'd have to use thunks or some other form of lazy evaluation. Macros allow you to just transform the unless statement into an if statement quite easily by just operating on the AST. Of course, you can do this without homoiconicity but it's a lot less ergonomic.

Also part of the reason Babel exists is to take the place of a macro system. Instead of transpiling array spread into a function polyfill, macros would just output the pollyfill into the AST. What's nice about this is that since it's userland, people can test drive new features. Rust did that for async/await. And the pattern matching proposal in JS is based off a SweetJS macro.

(Obviously not all language features can be implemented as macros but you get my point, right)

<comment><USER29> i think so. thanks for the explainer!

</comment></comment></comment></comment></comment><comment><USER31> I tried to learn (get to know) Clojure by writing a library for cacheing (memoizing) function calls. I thought it would be a simple exercise, but it turned out to be not so easy at all, with lots of special cases.

<comment><USER11> That seems like an unusual first project. Any reason you chose it? Were you more interested in the language semantics?

<comment><USER31> It was because (1) a project I was thinking of would lean heavily on memoized calls, and (2) it would allow me to learn about less basic features like introspection and (3) to quickly see how cleanly the language was designed to not be disappointed later on.

<comment><USER32> You could check out Clojure's built-in memoize ([https://clojuredocs.org/clojure.core/memoize](https://clojuredocs.org/clojure.core/memoize))

</comment></comment></comment></comment><comment><USER33> It is a good language. Python is easier for quick code.

<comment><USER18> I disagree. It's the matter of familiarity. Clojure is extremely productive and the best PL I have tried (out of many) to quickly build prototypes.

Whenever I have a requirement to solve a problem in a different language (e.g. interview challenge, etc.) I would still do it first in Clojure and then convert it to whatever language is required. Yes, I have to do the same work twice, but even then - I am still faster doing it that way.

</comment></comment><comment><USER34> > _Clojure is explicitly designed as a hosted language, which I think was a > very good move._

I'm not personally a fan of a VM such as JVM. Sure you get some easy benefits, but now you have two things that need tuning. Two things that need periodic updating.

Personally the total encapsulation of first-class static linking (such as Golang) is my preferred future. It must be first class and baked into the language in its design.

<comment><USER18> You're missing the point. Because Clojure is hosted you basically can share code between JVM and Javascript. It is extremely nice when you actually can do that. Even in NodeJS, essentially running on different implementations of the same platform - that is hard. As it turns out - not so hard in Clojure.

Now, imagine also having access to thousand of libraries written for JVM and Nodejs and Browsers? There are attempts to port Clojure to other ecosystems, making it possible to use them there. What if someday you can write Clojure code that can be shared between say Rust runtime, NodeJS and a browser? Wouldn't be that cool?

</comment></comment><comment><USER35> Clojure/Lisp is super nice until you have a bunch of transformations to make then you've to keep everything in mind without having a named reference in front of you (unless you omit the threading operators and abuse the let statement). It becomes exhausting after a while and makes you question if you are working for the machine or the machine is working for you.

Yes, it's more succinct and elegant but is it worth it?

<comment><USER36> You are absolutely free to decompose computations into more `defn`s, `let` statements, or threading operators. Or mix and match those.

<comment><USER35> You are 100% right but I am not writing all the code. My job is mostly maintaining other developers' code. And turns out, languages can have great effect on making not-so-good developer write reasonably good code (Go, for example).

<comment><USER37> One thing I've come to realize is that it is not enough to write code that's merely compilable. That's a low bar. A team needs a consistent style and that has to be enforced automatically. Automatic formatting is a good first step but that's also not enough. Say you don't want too many nested s-expressions. Then write a tool to reject code that has too many of them. Run the tool together with the compiler. Prevent merging if the tool complains unless a special exception is noted.

Tooling is important.</comment></comment></comment></comment>


Oakland wants you to stop calling it the "Next Brooklyn" - <AUTHOR> http://nextcity.org/features/view/oakland-gentrification-libby-schaaf-tech-industry-inequality-foreclosures

<comment><USER2> I honestly dont get this at all, If I could choose where I live I wouldnt choose where I live now, but I live where I can afford to live and if it became to expensive I would move, failing that I would buy a place where I wanted to stay then no one can make me move. The entitlement in this article is astounding.

</comment><comment><AUTHOR> _"... Oakland has long been at the center of a national conversation about equity, but it's quickly becoming a more enticing beacon for venture capitalism than for social justice. ..."_

</comment><comment><USER3> _Oakland, too, had a choice when the banks came for those foreclosed homes. It chose not to act while thousands of the city's most vulnerable residents were pushed out of their homes._

What choice was this, exactly? If it was to withhold assistance from banks seeking to foreclose, as the tone suggests, then that's flat-out wrong - evictions are legal actions that take place at the county level and are enforced by county sheriffs, and Alameda county is an awful lot bigger than Oakland - it's over 800 square miles, more than 10x the size of Oakland. Maybe the author meant the city could have approved more affordable housing development projects within its boundaries? My experience from attending planning committee meetings is that virtually any kind of development, large or small, is met with a storm of objections from local neighbors, and the planning committee seems to have an inordinate fondness for micromanagement, going so far as to specify paint choices on large buildings in pursuit of aesthetic harmony. Some of this is in response to California's poorly-written and seriously overbroad environmental quality law (CEQA) which allows people to file lawsuits over virtually anything.

This article has its heart in the right place (in terms of wanting to see the best outcome for the greatest possible number of people) but its factual grounding is rather poor.

Another example is the claim that there's no supermarket in West Oakland, and people must make the trek to the neighboring municipality of Emeryville. Well, this is technically true, but when you look at the map you can see that Emeryville juts into the center of West Oakland. Going there to get groceries does not strike me as such a big deal because it's only about 20-30 minutes' walk from any residential neighborhood in West Oakland - I know this because it's _my_ nearest supermarket, and I bring my groceries home in one of those fold-up shopping carts when I go there as neither my wife nor I like to drive and so we don't have a car. West Oakland is also well-served by public transport, including a free shuttle-bus operated by the Emeryville business community that runs from that shopping center to MacArthur BART station in Oakland. People who don't want to shop there also have the option of a smaller Trader Joe's (also technically in Emeryville, but about 1/2 mile closer to the center of West Oakland) or taking BART one stop and going to the Smart'n'Final in Downtown Oakland (an area that's much more accessibly from West Oakland than from where I live, farther north). The main downside of not having a supermarket in this part of Western Oakland (there are many others in other parts of the city) is that the sales tax revenue goes to Emeryville rather than Oakland - but then Emeryville also shoulders the burden of keeping up the roads around that busy shopping park, and so forth.

In practice, the municipal location of the supermarket is irrelevant - it's not like they check people's passports, and living only a few blocks from the Oakland/Emeryville border I can assure you that there isn't any big sociopolitical discontinuity when you cross the street from one to the other. The only big difference I've noticed is that there seems to be a larger number of apartment buildings in Emeryville, and construction permits and development projects seem to get approved faster there (possibly because it's smaller, and also because development is less politicized there).

<comment><AUTHOR> _"... Going there to get groceries does not strike me as such a big deal because it's only about 20-30 minutes' walk from any residential neighborhood in West Oakland ..."_

30 minutes walk is a deal breaker and from the article:

 _"... Oakland doesn't have the tax money it needs. Retail is broken here, ..."_

The broken part of settler cities (I'm from Melbourne) is ppl living without walking access to amenities. As a kid I lived within 5min of shops as I do now. Have access to buses, train, tram? If you don't you have to rely on private transport & that is bad.</comment></comment>


How I learned to write Chrome Extension in 5 hours using the Bruce Lee technique - <AUTHOR> https://medium.com/@punksomething/how-i-learned-to-write-a-chrome-extension-in-5-hours-by-using-the-bruce-lee-technique-c72911ac7d86 <comment><USER2> Just a heads up. calling it Netflix pro is most definitely a trademark violation..</comment>


A new type of software helps researchers decide what they should be looking for - <AUTHOR> http://www.economist.com/news/science-and-technology/21621704-new-type-software-helps-researchers-decide-what-they-should-be-looking

<comment><USER2> > In Dr Lichtarge's view, hypothesis-generation software works in part because > science writing tends to be free of humour, sarcasm and "emotive or literary > overlay" that could trip it up.

This looks like a decent argument to create some sort of publication language for science that describes hypotheses, methods, results and their linkages. Something a bit more formal and less varied that English that could be easily processed.

</comment><comment><USER3> This is a very interesting idea. We're already living in times where volume of information grows exponentially almost every year, and I believe that "filters" such as/similar to presented in the article will become more and more important part of our civilization. Partially, Google/HN are such "filters", selecting pieces of information that have some value for us. These days I'm thinking about AI/"Singularity" \-- I noticed that I envisioned Singularity as a single point in time, but now I think it's currently happening (like work on semiconductors or Turing's papers were the begining of information age). Why? Well, we're asking machines to give us clues on what to work on. It's not a formal argument but it's hard to provide one when it comes to predicting the future.

<comment><USER4> Can machines generate new questions?

[http://kiriakakis.net/comics/mused/a-day-at-the- park](http://kiriakakis.net/comics/mused/a-day-at-the-park)</comment></comment>


A Profile of the Average Startup Job Seeker – Infographic - <AUTHOR> http://blog.startupcvs.com/2016/03/01/profile-average-european-startupper-infographic/?utm_source=hackernews&utm_medium=social&utm_campaign=profile02032016 <comment><USER2> Do people specifically look for startups to work in? I have been applying for jobs over the last year. Went to one startup that was crap (didn't get paid). At another company now. Not a startup.I was more interested in the job and the tech stack being used.</comment>


Spoof UK Government's Brexit Propaganda - <AUTHOR> https://ledbydonkeys.com/ <comment><USER2> If they keep pushing a EU defense union, and northern Ireland backstop without an exit clause, the best deal is still 'no deal' on WTO terms.</comment>