21–30 of 68 posts
Swift is a nice language. What's really missing is better non-Mac support. Tools, libraries, etc. It'll become a Top 10 language (by popularity) once it becomes a real option for Linux and Windows.
Earlier quoted context omitted.
> It seemed there was a lot of focus on the more ML-ish aspects of its roots, such as the module system. The language also had a convincing future story for both green threads and garbage collection. So, OCaml?
Yes. In fact, the original compiler was written in OCaml. I would say the original intent was to be a lower level OCaml with optional safe control over allocation behavior and safe parallelism. I think he would probably have preferred OCaml syntax too. Notice some of the idioms, and even the capitalization/underscore norms (UpperCamelCase for types, snake_case for functions) are very similar to OCaml. But C syntax pr…
Earlier quoted context omitted.
XUL-based add-ons are being deprecated, and Firefox is adopting the same extension mechanism as Chrome (but with more extension points). That means that add-ons that make more or less drastic changes to the UI will need to be updated, rewritten or abandoned. This is being done before replacements of equivalent capability have been added to the new API. And there doesn't seem to be signs of awareness of the risks of d…
This is being done before replacements of equivalent capability have been added to the new API XUL support isn't removed yet, and the bugs and requests for feedback are open and out there. It's also possible to implement new WebExtension APIs (WebExtension Experiments) and inject them as an add-on, in order to test replacement APIs. Most of the major addon authors have engaged there, and many already have a WebExtens…
Earlier quoted context omitted.
> It seemed there was a lot of focus on the more ML-ish aspects of its roots, such as the module system. The language also had a convincing future story for both green threads and garbage collection. So, OCaml?
Yes. In fact, the original compiler was written in OCaml. I would say the original intent was to be a lower level OCaml with optional safe control over allocation behavior and safe parallelism. I think he would probably have preferred OCaml syntax too. Notice some of the idioms, and even the capitalization/underscore norms (UpperCamelCase for types, snake_case for functions) are very similar to OCaml. But C syntax pr…
(As an aside: Surely the capitalized version of snake_case is Snake_Case, not SnakeCase. Very few languages are consistent here.)
Earlier quoted context omitted.
> It seemed there was a lot of focus on the more ML-ish aspects of its roots, such as the module system. The language also had a convincing future story for both green threads and garbage collection. So, OCaml?
Yes. In fact, the original compiler was written in OCaml. I would say the original intent was to be a lower level OCaml with optional safe control over allocation behavior and safe parallelism. I think he would probably have preferred OCaml syntax too. Notice some of the idioms, and even the capitalization/underscore norms (UpperCamelCase for types, snake_case for functions) are very similar to OCaml. But C syntax pr…
Earlier quoted context omitted.
This is being done before replacements of equivalent capability have been added to the new API XUL support isn't removed yet, and the bugs and requests for feedback are open and out there. It's also possible to implement new WebExtension APIs (WebExtension Experiments) and inject them as an add-on, in order to test replacement APIs. Most of the major addon authors have engaged there, and many already have a WebExtens…
Interesting. Can you provide some links to the DTA situation?
(I've had to troubleshoot issues with Firefoxes being subtly broken due to how DTA injects into the network stack. That made for a rather biased reading of the above thread.)
Earlier quoted context omitted.
Yes. In fact, the original compiler was written in OCaml. I would say the original intent was to be a lower level OCaml with optional safe control over allocation behavior and safe parallelism. I think he would probably have preferred OCaml syntax too. Notice some of the idioms, and even the capitalization/underscore norms (UpperCamelCase for types, snake_case for functions) are very similar to OCaml. But C syntax pr…
I think this is the first time I see anyone like the OCaml syntax.
Swift is a nice language. What's really missing is better non-Mac support. Tools, libraries, etc. It'll become a Top 10 language (by popularity) once it becomes a real option for Linux and Windows.
Better Mac support would be nice too. Using Swift in a larger code base in Xcode often results in long compile times, auto completion and code syntax highlighting failures and other terribleness.
I think part of the problem is that they rely too much on SourceKit, which is a rather indirect and slow way to provide basic features like syntax highlighting and auto completion. These should be built into Xcode itself. As it is now, SourceKit has to do substantial work in a short amount of time which results in frequent crashes.
The compeller's error messages could use some improvement too, I don't consider 'BAD_EXEC' to be a descriptive error at all.
Earlier quoted context omitted.
Yes. In fact, the original compiler was written in OCaml. I would say the original intent was to be a lower level OCaml with optional safe control over allocation behavior and safe parallelism. I think he would probably have preferred OCaml syntax too. Notice some of the idioms, and even the capitalization/underscore norms (UpperCamelCase for types, snake_case for functions) are very similar to OCaml. But C syntax pr…
I think this is the first time I see anyone like the OCaml syntax.
Pattern matching for function heads is magical. Thus sayeth the Erlang fanboi.