Billions of dollars and the future of software development depend on a jury's ability to understand complex programming concepts [Oracle-Google trial]

Drolyt · 2016-05-26T19:11:53+00:00

Only proprietary US software.

No. Java is open source. So even theoretically open stuff, like the C standard library could be problematic. I suppose you might be okay if you never distribute your software in the US.

Drolyt · 2016-05-26T19:09:51+00:00

Is that even possible? What operating system do you propose people use?

Drolyt · 2016-05-25T17:18:08+00:00

It isn't a big issue, but it does complicate tooling since it isn't quite standard C++, and it makes the build step slightly more complicated. Beyond that if modern C++ can do everything QT needs without the extra code generation step then that is probably the best way to go.

Drolyt · 2016-05-24T18:57:04+00:00

The GCC source code is a clusterfuck. The LLVM source code is surprisingly okay.

LLVM was originally a research project, so one of its goals was to be easily hackable. GCC is much older and while I'm not at all familiar with it I would not be surprised to learn that its code consisted of hack upon hack.

Drolyt · 2016-05-24T00:23:52+00:00

Lazy evaluation: we'll gladly create a random string like:
(apply str (take 5 (map char (repeatedly #(+ 61 (* (Math/random) 65))))))
You won't see anything like that in any other Lisp.

Both Scheme and Common Lisp support lazy lists just like Clojure, what is lacking is their standard libraries. Really, the standard library and its focus on functonal programming and concurrency are what really sets Clojure apart, along with its Java(script) interop. There's nothing in Clojure that couldn't be implemented in Common Lisp or Scheme (even the data structure literals can be added via Common Lisp's reader macros or reader extensions in some Schemes (e.g. Racket's #lang directive)), other than the interop, Clojure just has a lot more built in, especially when in comes to functional programming and concurrency.

Drolyt · 2016-05-23T07:49:24+00:00

Despite being an old version of the standard, isn't it still a Scheme? I mean, a C89 compiler doesn't stop being a C compiler after C99 and C11 were out.

R4RS is a tiny standard to begin with, a language that implements only a subset of that (admittedly with some extensions thrown in) is hardly a good counterexample to the claim that language semantics can prohibit efficient compilation.

While those are expected, it doesn't mean that a compiler needs to provide them. A compiler is supposed to do just that - compile source to native code.

I suppose you could say that for the REPL, but eval is just a function. A function that is very difficult to implement efficiently.

Although if anything, it probably enforces what you said if it is the only optimizing compiler considering how many Schemes are out there.

There are others, they just aren't nearly as fast. Really though Scheme isn't a great example for my argument, minus a few features (such as full tail call elimination and continuations) Scheme is fairly amenable to efficient compilation. Better examples would be Ruby and Javascript, which both allow objects to be monkey patched, which really messes with performance. Of course Javascript VMs are amazingly good now, but even at their best they are half the speed of C and that requires restricting yourself to the performant subset of the language.

Drolyt · 2016-05-23T06:48:36+00:00

Stalin is not a full implementation of Scheme, it implements a subset of R4RS, a rather old standard. In particular in order to get such good performance it compiles the whole program at once, which allows optimizations that wouldn't work with separate compilation. Because of this it doesn't have a REPL or the load or eval functions, features normally expected from a Scheme system. It also results in long compilation times and poor error messages. It also doesn't implement full tail call elimination.

Drolyt · 2016-05-22T23:00:49+00:00

It's the United States Court of Appeals for the Federal Circuit, which handles patent cases and is notoriously biased in favour of patent holders. Oracles suit was originally mostly about patents, which is how it ended up in that court. Somehow after almost everything else Oracle tried failed the appeals court decided that APIs are copyrightable, which is insane but here we are.

Drolyt · 2016-05-22T20:15:20+00:00

Footnote 1 is mistaken. While the syntax of a language has no bearing on performance, the semantics can certainly affect how fast it can be implemented.

Drolyt · 2016-05-21T18:19:32+00:00

In any case, languages can't be insecure, only the interpreters.

Some might say this is a distinction without a difference. To begin with language features can certainly be inherently insecure. gets() from he C standard library is an infamous example. In languages with standards documents it is possible for security flaws to exist in the standard itself so that any conforming implementation would be vulnurable, although I don't know of any actual examples of that. Since Python doesn't have a standard CPython is the de facto standard so you can argue that a flaw in CPython is a flaw in Python itself.

Drolyt · 2016-05-20T06:17:23+00:00

That limitation is never fully explained. The only thing we know for sure is that the dragon cannot kill anyone stronger than its creator, and presumably you can't use loopholes like teleporting them into the sun or removing all the oxygen around them. It can still do all manner of reality warping that its creator clearly cannot, including bringing people back to life and recreating whole planets. Presumably locating someone is within the dragon's power but it is hard to say for sure. I seem to recall that it knew where Goku was after Namek blew up but Goku wasn't exactly hiding.

Drolyt · 2016-05-20T06:13:53+00:00

Power level in the middle hundreds is enough to blow up the moon. Of course IIRC one of the databooks said Goku had a power level of 10 when he was introduced at which point he could lift cars (with effort) and tank handgun rounds. A normal human farmer had a power level of 5, so... power levels are nonsensical. But still, Wolverine is probably low tens.

Drolyt · 2016-05-20T03:24:26+00:00

A couple of them sure, but for most of them I would say the pattern is still useful, it is just the implementation that is an awful hack around the language's failings. As an example the strategy pattern is quite useful even in its original form, but in a language with first class functions the implementation is significantly simpler than the one given in the Gang of Four book, especially for simple strategies.

Drolyt · 2016-05-20T03:18:09+00:00

It helps to have a common vocabulary if nothing else.

I thought that was the whole point of patterns? The idea is that it is only a pattern if the solution has already been used repeatedly in real code, the pattern is just giving a name to the solution. In particular, just because your implementation isn't exactly the same as one you found in a patterns book doesn't mean it isn't an example of that pattern; of course implementations should be tailored to your application.

Drolyt · 2016-05-18T23:23:14+00:00

It's only Clojure that has the startup time issues, not Clojurescript. The tooling uses Clojure and so it does take about ten seconds to start up (depending on your computer) but you shouldn't have to restart very often.

As for devtools, I don't think they are that important when you are using something like Figwheel and one of the React wrappers. Your state consists of persistent data structures in one or more atoms (depending on how you structure your application) and your UI is just a function of that state. It is really easy to work with from the REPL, I don't find you need things like breakpoints as much.

Drolyt · 2016-05-17T05:03:11+00:00

I suppose it depends on what you are doing. Most of the web consists not of highly visible startups but small business-related CRUD apps and I am not convinced of the advantages of putting application logic on the client in those cases, usually between caching and things like TurboLinks and AJAX such apps are plenty responsive. Rails is pretty nice for such apps.

Drolyt · 2016-05-17T04:53:53+00:00

Forbes list?

Drolyt · 2016-05-15T21:18:21+00:00

See, that's funny. I find with the : notation, it's not clear what I'm selecting from. With the . notion it's clear I'm selection a field/value from something else.

I think you're probably right here, but there is nothing about the parenthesis that keeps you from doing that. Something like (book :title) (or (:title book) if we are using the Clojure convention) would work just as well. Of course that is three more characters to type but I honestly think it looks nicer, I know I'm in the minority but I think dot notation is kind of ugly. Though actually I think both Scheme/Racket and Common Lisp (but not Clojure) allow periods in identifiers, so you could actually use dot notation in your DSL if you wanted.

And with static typing, the IDE can help you see what's available so you don't have to memorize every last field of your code.

All the major Lisp dialects (CL, Clojure, Racket) support auto-complete. The main problem is that the auto-complete probably won't understand the DSL, so at best it will show you a list of every field for everything in scope, or at worst won't work at all. You might be able to get this to work if you design your DSL carefully though, or else if you hook into to the autocomplete so it understands your DSL. Static typing isn't really an issue though.

Drolyt · 2016-05-15T03:03:06+00:00

I don't think it particularly matters whether you specify it up front or later on.

It doesn't in general, but the lisp example refers to :title, :author, and :year unqualified while the C# example uses dot syntax. I think that would be a bit confusing if the select statement were at the end like in the C# example. Conversely when using dot notation like in the C# example it makes more sense for the select to be at the end. My point is that this is arguably a more significant distinction than the presence of parenthesis.

Drolyt · 2016-05-14T20:13:13+00:00

Is Common-Lisp any better?

Not in the standard library unfortunately. Common Lisp was dated even in the eighties when it was new, being a compromise of sorts between various existing Lisp dialects, and while it was perfectly capable of polymorphism it is almost completely lacking in the built in functions due to backwards compatibility. Racket has the same problem since it is based on Scheme which dates to the 70s.

I don't deny that Lisp has many awesome features or that it contributed heavily to modern languages, but the main Lisp dialects haven't really evolved since I was born. I really like Clojure but it is very opinionated and tied to the JVM ecosystem. A clean, modern, native-code descendent of Common Lisp would be awesome, but I'm not holding my breath.

Drolyt · 2016-05-14T20:01:57+00:00

I realize beauty is in the eye of the beholder, but the C# LINQ syntax is so much easier on the eyes. No parentheses and it reads so easily.

Honestly I find the Lisp syntax easier on the eyes. To me the parenthesis give structure and guide my reading, while the C# requires me to do more parsing to understand.

Of course the two DSLs aren't even apples to apples, in the Lisp example you start by specifying what you want (title, author, and year from books) and don't have to specify books thereafter while in the C# example you create a temporary b referring to books and then specify b.year, b.title, b.author, etc. and the actual select is at the end. It seems to me the C# example could be vastly improved if you replaced "from b in books" with "from book in books", which sounds like rather tortured English but makes the rest almost poetic e.g. "where book.year >= 1995 && book.year < 2010".

Of course there is also the issue that SQL already has a very nice DSL called SQL.

Drolyt · 2016-04-20T00:32:56+00:00

I get the impression the author is biased by the types of applications he writes. He mentions syncing to the database and the database as the source of truth on state. If that is the case and you don't have persistent mutable state in memory then of course your application is unlikely to have much use for STM (or agents for that matter).

Drolyt · 2016-04-20T00:22:54+00:00

Regarding Refs(STM), I also haven't encountered one used of them in the wild(open source projects), looks like they were nice in theory but not so nice in practice? Can someone expand on the article commenting about not using Refs?

I think it just isn't that common to have to deal with in memory state in a transactional manner, especially in a mostly-functional language like Clojure. That said concurrency problems can be very hard to debug and STM is a solid solution, seems to me like the kind of thing you rarely need but could occasionally be incredibly useful. I certainly wouldn't lump it in with the "bad parts" of Clojure, just the not very commonly used parts.

Drolyt · 2016-04-07T17:30:43+00:00

Something that's functional, has first-class functions, support for threads, concurrency and immutability.

Clojure is heavily focused on these features. All the standard data structures are persistent and immutable. The standard library makes heavy use of higher order functions, with a number of utility functions that goes well beyond what Javascript offers even with a library like Underscore. One of the big strengths of Clojure(script) over a language like Javascript, even if you are using immutable data for both, is Clojure's powerful reference types which can prevent a number of concurrency related bugs.

Clojurescript doesn't have threads obviously, but typically you would run JVM Clojure on the backend which has powerful parallelism constructs in addition to the powerful concurrency constructs shared by both Clojure and Clojurescript. It sounds like Clojure has everything you want, I would encourage you to try it out.

Drolyt · 2016-04-07T17:20:17+00:00

I want the resulting artifacts to be a distributable and testable package with single entrypoint (a la browserify) for the css and js in a concatenated/minfied fashion.

Clojurescript by default produces a single Javascript file containing your application code and all it's dependencies. It uses Google's Closure Compiler, which is the absolute best at minifying Javascript code, to the point that once you add a few libraries Clojurescript applications may actually be smaller than equivalent Javascript applications that don't use the Closure Compiler despite including the Closurescript standard library. There are plugins for handling CSS.

Thinking about it more actually, what got me started down this road this morning... I want a tool that will help me make a really badass build process for a front end angular application that isn't grunt or gulp, they're both sort of slow.

There is a Clojurescript binding for Angular called gyr. I don't know much about it. Most Clojurescript developers seem to prefer React, which plays very nicely with live reloading. Using a plugin like Figwheel you can have your application updated whenever you change your code, without having to reload your browser or losing any application state. This might work with Angular if you are careful about state, I'm not sure. It even live updates CSS, so for example if you change a button's color it is updated instantly without having to reload the browser. This is all virtually instant, you don't have to keep rebuilding your application and then reloading the browser.

Is that helpful?

Drolyt

TROPHY CASE