Gilad Bracha

From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages.

What is frustrating is that there are so many people who can do this job right, yet we are stuck with amateurish programming languages designed by companies like Google. Please try and hire people like Oleg Kiselyov, Simon Marlow, Erik Meijer or some one from the possible hundreds who have worked deep in PL theory for literally decades. On the face of it Gilad Bracha has great credentials, credentials that would make the HR folk happy but one look at some of the stuff he writes and we know things are not going to be good.

http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html

I think Phil Wadler gave him more respect than was due in the comments :-) Microsoft hired Anders Hejlsberg for .Net which I don't think was a good idea, he is a great engineer but not a PL theory expert. They however "rectified" the situation by hiring Erik Meijer later and his impact via LINQ and F# and improvements in C# is obvious. Not to say that Hejlsberg is not good, but Meijer is better. Getting back on track, I may be wrong but Dart makes me groan. It is one thing to design such a language in 1990, but quite another thing to do it…

Hm. I have mixed feelings about this project (judging solely from the video presentation). On one hand, it is very impressive, no question about that. The sheer amount and diversity of stuff in it would require a degree of focus that makes me feel envious even after this very superficial examinaton. On the other hand, the choice of which stuff to put in just disagrees with how the boundaries are drawn in my head—I’d would have thought a file monitor and a build system/dependency tracker were separate tools, while expecting at least the simple part of migration boilerplate to be generated.

But I guess that’d require hooks into the compiler frontend, which is not just goes against your goal of being relatively compiler-agnostic but is also fantastically difficult for C++. (I wonder if DWARF contains enough data to at least transfer over identically-named fields?.. It’s also something of a bear, but nowhere near a full C++ frontend.) I don’t know how this could be useful to you, sorry. Thank you for showing your project, I’m grateful for the food for thought in any case.

Now, can we just all take a moment to appreciate that you needed a Smalltalk-style become:[1] and ended up making an object table, precisely the classic Smalltalk way? In the end it’s either that or precise pointer tracing, there isn’t (AFAIK) a lot of choice, but it’s still amusing to see an ostensibly high-level mechanism reproduced in a very different environment.

[1]…

Computer language inventors are torn between a voice whispering “use the language Luke” and and a more gravelly “let your feelings for the compiler grow, embrace the syntax side.”

I did a two-day sprint through Zig a month ago and really really liked it. It has some quirks that I would have done differently, but overall I think it’s pretty cool. I just need a good small scale project to try it out on now.

My favorite example of the “use the language” ethos is the way Zig does generics. I have hated generics/templates in every language I use them in. They are the gordian knot of confusion that most languages in pursuit of some sort of unified type theory impale themselves on (yes, I’m mashing metaphors here). But Zig just uses its own self to define user types and generics come along for free. It resonates (with me at least) as a realization of what Gilda Bracha has shared about how to reify generics.

[1] https://gbracha.blogspot.com/2018/10/reified-generics-search-for-cure.html?m=1

I would question your assumption that "clean code" that you describe is really modularization and abstraction. (In particular, separating everything into small scattered pieces, which is IMHO a horrible Java habit that I have to endure now.)

I mean, both modules and abstractions should have purpose.

The purpose of modules is to "do one task well" so to speak. So if for a typical change you need to modify several of them, you're not modularizing it right.

The purpose of abstraction is to provide another "language" which lets you forget certain technical details, while clarifying the bigger picture. Again, unless this language has been designed wrong, you shouldn't have to touch the abstraction.

Addendum: Of course, there is also the classic https://gbracha.blogspot.com/2011/06/types-are-anti-modular.html (and we can consider types to be a form of abstraction), so to some extend these things go against one another.

> once you use an IDE that actually IS "integrated" as the acronym suggests, you will never turn back.

If you're unfamiliar with Smalltalk environments and are wondering what this actually means, watch this 3-minute video showcasing a Smalltalk IDE -- the class browser, method finder, and debugger:

http://vimeo.com/27850933

Anything else seems so... primitive by comparison.

Smalltalk's great drawback is over-reliance on the image:

"If your program misbehaves (and they always do) and corrupts the state of the process, things get tedious. Say you have a test that somehow failed to clean up properly. In a conventional setting, you fix the problem with your code, and run the test again. With an image, you have the added burden of cleaning up the mess your program made. [...] In general, Smalltalk makes it hard to [...] separate the application from the IDE."
-- http://gbracha.blogspot.com/2009/10/image-problem.html

I thought this http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html?showComment=1296027246940#c6671808644893652655 was a fantastic comment.

Sending a message on a channel usually costs at least a compare-and-swap or memory fence. This limits their applicability to things above a certain granularity [...] even in Erlang or Scala actors, you wind up passing around lists and other concrete data structures, because it isn't worth constructing those queues _everywhere_.

So when is a distributed program's internal communication and IO the right level of granularity?

Network IO would seem to be a familiar instance of an Actor model and should map directly.

Interestingly, Intel's new Xeon Phi chip http://semiaccurate.com/2012/11/12/a-look-at-the-xeon-phi-cards-and-hardware/ "looks like a cluster of x86 servers that are on a TCP/IP network, and takes almost no programming expertise to port to."