Dart language • Hacker News Board

Re: Dart language

#501

Post by justncase80 » Thu, Oct 13, 2011, 4:14 PM UTC

bad_user wrote: post #339

zohebv wrote: post #65

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 d…

On Anders - you're not giving him enough credit. C# had a hard constraint to start with - it was supposed to be an easy replacement for Java, it actually started from Microsoft's own Java implementation and it had to ship as fast as possible. Even so, the language evolved nicely as they left room for improvement in a forward-thinking manner. Also, C# 1.1 did have 5 things which I terribly miss from Java - delegates,…

word. Anders is awesome.

Re: Dart language

#502

Post by WayneDB » Thu, Oct 13, 2011, 7:33 PM UTC

seasoup wrote: post #484

WayneDB wrote: post #440

Earlier quoted context omitted.

People also used to program computers with punch-cards. Everyday. Of course they can use Javascript. You didn't address any of his points though. Where are the great Javascript tools and IDEs? There are tons of them for languages with static typing and classical inheritance. Here's just one tiny example: Compare how you go about refactoring code (renaming classes, functions, etc) in Javascript with the many ways that…

He made many points, Javascript not having great tools and IDE's is only one of them. It's a valid one though, the Javascript IDE's out there aren't very good. However, that's a function of community support, not language quality. Personally, I don't use an IDE for javascript or RoR programming, I just use Textmate. I use Eclipse for Java programming, and I don't think I would want to program in Java without it. Mayb…

Actually, many people have tried to build refactoring and editing tools for JS and they always hit the same limitations. The language is just not conducive to tooling. Without a great refactoring tool, big projects become difficult.

Re: Dart language

#503

Post by dingfeng_quek » Wed, Oct 19, 2011, 11:59 AM UTC

6ren wrote: post #496

dingfeng_quek wrote: post #434

Earlier quoted context omitted.

It is easy to agree that there MUST be essential dependencies between modules in a system designed separated in a certain way. (Ignoring some philo arguments on identity, separation and reference point...) The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of…

> The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique. I'm not sure exactly what you mean. Could you elaborate please? I'll clarify my view with an analogous example: you can think of a database as having a set of types - its schema. Thi…

Typing adds constraints - the type must be represented by and implemented in a particular type system. A trivial anti-modular constraint is that interacting modules must all use the same type system. The type system matters too - in Java, choosing from easily implementable types can easily add a lot to the complexity of the data structure, leading to a complex interface (in a more expressive type system, less of this happens).

More trivially, adding types IS adding constraints that are verifiable at compile time.

If compile-time verification of that sort is not essential (or not desired, which is the more general form of not essential), then the constraints are non-essential (or not desired).

---

Whether you choose to

1. Choose a particular data-structure and implement both modules to pass and receive that data-structure.

2. Specify an interface: The interface requires the data-structure to have certain properties (e.g. some methods work on them). The modules then build to the interface.

3. Specify that an adaptor exist to convert the data-structure to whatever the module requires.

is a somewhat different issue, although the kind of type system used does affect the implementation complexity and effort required.

Re: Dart language

#504

Post by JimBlandy » Thu, Oct 20, 2011, 2:07 AM UTC

justncase80 wrote: post #499

JimBlandy wrote: post #487

Earlier quoted context omitted.

At a technical level, virtual machines are not the panacea many folks seem to think. Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs. But what no virtual machine will ever do is make modules written in different source la…

It seems to allow for more variation in languages. The only time you really need to worry about those other languages is when you're trying to load modules written in other languages. At least that's how it works in .net. You can have pretty significant semantics from language to language and as long as you don't care about other languages actually loading your modules then it doesn't matter. If you concede that the…

Oh, targeting a good VM is a huge win over a typical machine language for an implementer. My prediction is specifically that the inter-language paradise some expect will never come.

But even within the points you bring up, I'm not sure that VMs are as winning as they're made out to be. Size and compilation time aren't somehow intrinsically better for VMs; JS does quite well on both fronts these days. And I'm not convinced JS's quirks are harder for implementers to cope with than a silicon machine language's.