Re:Scopes – Retargetable programming language and infrastruc...
by manifestsilence on Monday May 06, 2019 @09:19AM
(#19839117)
Haha, I read it as rechargeable. I hoped that meant that it would somehow inject new functionality to avoid the ravages of time and not eventually be looked at like Cobol is.
Re:Scopes – Retargetable programming language and infrastruc...
by giornogiovanna on Monday May 06, 2019 @01:17AM
(#19837041)
The introduction mentions "view propagation", which does borrow checking without annotations. Is this documented anywhere?
Also, I wish more languages had homepages like the Go one[0]. It takes a lot of reading to get to the point where you can see some non-trivial code[1], which is frustrating.
Re:Scopes – Retargetable programming language and infrastruc...
by jonathanstrange on Monday May 06, 2019 @05:09AM
(#19837867)
I was thinking the same, the pages need redesign. The best way to make people try out a language is to give an example on the first page (without scrolling). It should be more than "hello world", e.g. 99 bottles of beer or Fibonacci numbers, anything that shows me how the language looks & "feels".
That being said, this looks like a really interesting and promising language. If the borrow-checker is unobtrusive and doesn't require ridiculous boilerplate, then you can count me in! Good work!
Re:Scopes – Retargetable programming language and infrastruc...
by Rusky on Monday May 06, 2019 @02:50AM
(#19837328)
There's no technical reason the Rust borrow checker couldn't run without annotations either- that's a design choice, similar to the way Rust requires function types even though it could infer them. It makes inter-function contracts clearer, which improves error messages, and avoid the need for whole-program analysis.
I couldn't find anything more about "view propagation" either but I strongly suspect it's no more powerful. Probably less and/or buggier at this point, given its relative maturity.
Re:Scopes – Retargetable programming language and infrastruc...
by giornogiovanna on Monday May 06, 2019 @11:33AM
(#19840333)
Thanks, so lifetimes can definitely be inferred for safe code (although just like type inference, they can lead to leaky abstractions). But aren't lifetime annotations necessary for unsafe code? How could you cast a pointer into a struct into a raw pointer and back, while preserving the lifetime, without them?
Re:Scopes – Retargetable programming language and infrastruc...
by Confusion on Monday May 06, 2019 @05:03AM
(#19837841)
What I would be very interested in seeing in an introduction to a new language is an explanation of why the authors think other languages that intend to support a similar combination of features have failed to achieve that or have failed to get traction.
These kinds of introductions always read like "we're going to combine these and these and these awesome features from all your favorite languages" and well, what's not to like? Wouldn't everyone want this? So I can't help but wonder: why didn't anyone previously succeed at creating such a language? What are you going to do differently?
Re:Scopes – Retargetable programming language and infrastruc...
by sanxiyn on Monday May 06, 2019 @08:25AM
(#19838737)
This answer will not satisfy you, but I can answer this as someone who worked on design and implementation of multiple programming languages: Q. why didn't anyone previously succeed? A. Nobody tried.
There are a LOT of decisions that go into design and implementation of programming languages. Due to combinatorial explosion, vast majority of combination was never tried. This is still true even after you group "similar" combinations. But usual standard of similarity used by many people is "How is Rust different from Go?", which is too laughable to answer. To me, Scopes seems different enough that the author should not feel any need to answer questions like yours.
Re:Scopes – Retargetable programming language and infrastruc...
by nickpsecurity on Monday May 06, 2019 @09:28AM
(#19839181)
I'll add to your answer that a lot of them aren't production-worthy either. That might be the packaging, lacking a standard library, not integrating with whatever is dominant in that space, no docs on basic usage, and so on. This happens with verification tools in CompSci, too.
So, they need to get a combination of features to whatever is the minimum of usability the target audience expects. I also push for it to integrate well with legacy libraries with no overhead. Scope author is doing that for C libraries. As a side effect, it's a big boost on productivity since people can always lean on whatever libraries are already there.
Re:Scopes – Retargetable programming language and infrastruc...
by dTal on Tuesday May 07, 2019 @05:22AM
(#19847763)
I was gonna say - I already have a language with the expressivity of Scheme, the convenience of Python, and the performance of C - it's called "Chez Scheme". Why isn't it popular? Because A) the performant implementation was proprietary until relatively recently, and B) it's less "batteries included" and more "that drawer in your house full of batteries, most of which are dead". There's a great language in there, but it lacks the tooling and social structures for popularity.
Re:Scopes – Retargetable programming language and infrastruc...
by nickpsecurity on Tuesday May 07, 2019 @09:47AM
(#19849236)
Racket is being ported to Chez Scheme. That might solve the batteries included problem at least at the Racket level. However, if you don't like Racket, then I don't know if it will do anything since using Racket's libraries in Chez might be too kludgy to attempt.
Since you're a Chez fan, I'll also throw in its historical overview in case you missed it. That they had Scheme on 8-bitters really tripped me out. Talented team.
Re:Scopes – Retargetable programming language and infrastruc...
by CharlesMerriam2 on Sunday May 05, 2019 @11:17PM
(#19836577)
The bar for a new programming language is higher than ten years ago.
Introducing a language should now include "What are the cool new things in this language?" The short list where this shines, e.g., "Go - compiles really fast and no classes". "Rust - deep safety and a novel macro system". "Python - Batteries included and easy to write."
A language also needs to include some design philosophies. Sometimes its simple: "DRY"; sometimes its the tradeoffs ordered in Zen of Python. You need to say something.
Re:Scopes – Retargetable programming language and infrastruc...
by jerf on Monday May 06, 2019 @09:59AM
(#19839434)
With no direct disrespect intended towards these authors in particular, I'll believe "expressivity of Scheme with the convenience of Python, Lua or Javascript and the performance of C" when I see it. Goals aren't results. I've seen that goal a lot. Given how often I've seen it, and how I'm yet to see a result that matches it, I'm coming around to the assumption that that set of goals is probably just not possible. (I suspect Python, Javascript, etc. are fundamentally, in their very core, based on some operations and conveniences that are just fundamentally going to be slow on modern processors. The only way around it is to drop some of the conveniences. That I have seen be successful.)
On the "goals aren't results" front, the second one is also one that I'd want to see how it plays out a bit more before getting too excited; it's also possible that it may not be possible at it currently exists in the author's heads.
Re:Scopes – Retargetable programming language and infrastruc...
by jonathanstrange on Monday May 06, 2019 @05:01AM
(#19837832)
Out of curiosity, the docs state that closures are supported as zero-cost abstractions. That seems to imply that the language can store environments at zero cost. How is that possible?
Re:Scopes – Retargetable programming language and infrastruc...
by sanxiyn on Monday May 06, 2019 @08:09AM
(#19838625)
It does not imply that. Closures are usually implemented with environments, but this is unnecessary. You can compile so that everything that would be in the environment is passed as arguments. It seems to me Scopes is implemented this way.
> C/C++ requires programs to be built and linked before they can be executed. For this, a build system is typically employed.
> In contrast, Scopes’ primary execution mode is live, which means that the compiler remains on-line while the program is running, permitting to compile additional functions on demand, and to use other services provided by the Scopes runtime library.
Re:Scopes – Retargetable programming language and infrastruc...
by ahaferburg on Monday May 06, 2019 @03:47AM
(#19837536)
Note the word primary.
> However, Scopes can also build object files compatible with GCC and Clang at runtime using compile-object, which makes it both suitable for classic offline compilation and as foundation for a build system.
Also, I wish more languages had homepages like the Go one[0]. It takes a lot of reading to get to the point where you can see some non-trivial code[1], which is frustrating.
[0]: https://golang.org
[1]: https://scopes.readthedocs.io/en/latest/tutorial.html#a-mild...
That being said, this looks like a really interesting and promising language. If the borrow-checker is unobtrusive and doesn't require ridiculous boilerplate, then you can count me in! Good work!
I couldn't find anything more about "view propagation" either but I strongly suspect it's no more powerful. Probably less and/or buggier at this point, given its relative maturity.
struct A<'a, 'b>(&'a u8, &'b u8);
and
struct B<'a>(&'a u8, &'a u8);
without lifetime annotations?
These kinds of introductions always read like "we're going to combine these and these and these awesome features from all your favorite languages" and well, what's not to like? Wouldn't everyone want this? So I can't help but wonder: why didn't anyone previously succeed at creating such a language? What are you going to do differently?
There are a LOT of decisions that go into design and implementation of programming languages. Due to combinatorial explosion, vast majority of combination was never tried. This is still true even after you group "similar" combinations. But usual standard of similarity used by many people is "How is Rust different from Go?", which is too laughable to answer. To me, Scopes seems different enough that the author should not feel any need to answer questions like yours.
So, they need to get a combination of features to whatever is the minimum of usability the target audience expects. I also push for it to integrate well with legacy libraries with no overhead. Scope author is doing that for C libraries. As a side effect, it's a big boost on productivity since people can always lean on whatever libraries are already there.
https://blog.racket-lang.org/2019/01/racket-on-chez-status.h...
Since you're a Chez fan, I'll also throw in its historical overview in case you missed it. That they had Scheme on 8-bitters really tripped me out. Talented team.
https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf
Introducing a language should now include "What are the cool new things in this language?" The short list where this shines, e.g., "Go - compiles really fast and no classes". "Rust - deep safety and a novel macro system". "Python - Batteries included and easy to write."
A language also needs to include some design philosophies. Sometimes its simple: "DRY"; sometimes its the tradeoffs ordered in Zen of Python. You need to say something.
So, what's this new language do again?
From their page:
- Aims to combine the expressivity of Scheme with the convenience of Python, Lua or Javascript and the performance of C.
- Compile-time resource management using view propagation, an annotation-free variation of borrow checking.
- Support for live code execution as well as offline compilation of object files.
- Statically typed but fully inferred type system via forward propagation. Supports closures as zero-cost abstraction.
etc.
I don't know how tough the crowd is nowadays but I was already sold when I read the 1st and 2nd items above.
On the "goals aren't results" front, the second one is also one that I'd want to see how it plays out a bit more before getting too excited; it's also possible that it may not be possible at it currently exists in the author's heads.
[0] https://lritterdevlog.hashbase.io/#toc8
Accessible through this page via the hamburger menu > click “Read the docs”:
https://scopes.readthedocs.io/en/latest/
> C/C++ requires programs to be built and linked before they can be executed. For this, a build system is typically employed.
> In contrast, Scopes’ primary execution mode is live, which means that the compiler remains on-line while the program is running, permitting to compile additional functions on demand, and to use other services provided by the Scopes runtime library.
> However, Scopes can also build object files compatible with GCC and Clang at runtime using compile-object, which makes it both suitable for classic offline compilation and as foundation for a build system.