Nairaland Forum / Science/Technology / Programming / Astro Programming Language 0.2 (indefinite release) (32889 Views)

Hurray....a Yoruba Programming Language Is Here / Is It Advisable To Learn Java As My First Programming Language? / Which Programming Language Is Used In Programming Sim Cards? (2) (3) (4)

(1) (2) (3) (Reply) (Go Down)





Now after a year of designing the language, we have managed to come up with an interpreter that is near completion (there are still lots of bugs to fix and changes to make) and as co-developer, I felt we need to start promoting the language.



No production-ready language has made it out of Africa yet, but we hope to stop this unusual trend with the introduction of Astro.



This thread will focus on providing information about Astro until its release.



Astro's concise documentation can be found



Below are planned features and paradigms of the language (some are not yet implemented):

- Procedural

- Object-oriented

- Fast Performance

- First-class Functions (Anonymous Functions, Closures)

- Anonymous Types

- List Comprehension

- Events

- Generators

- Concurrent Coroutines

- Properties

- Expression-oriented

- Optional Typing

- Union Types

- Operator Overloading

- Generics

- Regex

- Exception Handling

- Multiple Inheritance

- Multiple Dispatch

- Unified Function Call Syntax

- Unicode String Support

- Unicode Identifiers

- Algebraic Data Types and Pattern Matching

- Type Inference

- Package Manager

- Meta Programming

- AST Macros

- Automatic Reference Counting (No tracing GC)



Some of these things may not be familiar, but they are actually just big grammars for simple concepts.

Unified Function Syntax Call, for example, simply means being able to use dot notation with ordinary functions.

So

play(music, 'backwards')

Can be called using its first argument.

music.play('backwards')



Questions, comments, criticisms and suggestions are welcomed.



Thanks for reading.



UPDATE:

A lot has changed about the language since the time of this post and Astro now adopts sem ver, so the version shown above is now incorrect as of this update. Syntax and implementation details have changed quite a bit too. I'm a co-developer of the Astro programming language, originally started by Nypro. Astro language specification has reached version 0.2, but no stable interpreter was written for it until recently due to the constant changes in syntax and semantics of the language.Now after a year of designing the language, we have managed to come up with an interpreter that is near completion (there are still lots of bugs to fix and changes to make) and as co-developer, I felt we need to start promoting the language.No production-ready language has made it out of Africa yet, but we hope to stop this unusual trend with the introduction of Astro.This thread will focus on providing information about Astro until its release.Astro's concise documentation can be found here . It's actually meant for the developers of the language, but since we don't have a proper documentation yet, it's the only place to get a grasp on how Astro syntax looks. The syntax is, however, not final yet, so we make sure we commit every change as they are made.Below are planned features and paradigms of the language (some are not yet implemented):- Procedural- Object-oriented- Fast Performance- First-class Functions (Anonymous Functions, Closures)- Anonymous Types- List Comprehension- Events- Generators- Concurrent Coroutines- Properties- Expression-oriented- Optional Typing- Union Types- Operator Overloading- Generics- Regex- Exception Handling- Multiple Inheritance- Multiple Dispatch- Unified Function Call Syntax- Unicode String Support- Unicode Identifiers- Algebraic Data Types and Pattern Matching- Type Inference- Package Manager- Meta Programming- AST Macros- Automatic Reference Counting (No tracing GC)Some of these things may not be familiar, but they are actually just big grammars for simple concepts.Unified Function Syntax Call, for example, simply means being able to use dot notation with ordinary functions.SoCan be called using its first argument.Questions, comments, criticisms and suggestions are welcomed.Thanks for reading.A lot has changed about the language since the time of this post and Astro now adopts sem ver, so the version shown above is now incorrect as of this update. Syntax and implementation details have changed quite a bit too. 5 Likes 4 Shares

-------------------------------------------------------------------------------------

Astro is influenced by languages I like (C++, Python, Julia). I'll be watching that repo. 1 Like



I'll be watching I love this...I'll be watching 1 Like

Craigston:

Astro is influenced by languages I like (C++, Python, Julia). I'll be watching that repo. You are right. Astro is like a nephew to Julia. Astro borrows a good deal of Julia and Python Syntax but it also takes useful concepts from Scala, C#, CLOS, Ruby, Go, Java, etc.



Infact there is a short list of where Astro borrowed certain concepts.



Julia

- Multiple dispatch

- AST Macros

- REPL

- Syntax - '<:', '>:', array Indexing, macros, etc.

- Numeric types

- Math-oriented arrays

- Unicode Identifiers



CLOS

- Multiple Inheritance



Python

- Syntax - lists, loops, in, etc.



Jai

- Compile-time execution

- Syntax - generics



Ruby

- Block end punctuation



Crystal

- Sophisticated static type inference



Lua

- List/Dict implementation

- Bytecode representation



Go

- Concurrency model

- Syntax - access modifier blocks, 'func', etc.



Swift's

- Automatic Reference Counting

- Optionals (Nullables)

- Pattern matching

- Syntax - where, let, var, etc.



Scala

#- Match functions #

- Constructor types

- Infix notation

- Singletons



Java

- Anonymous types



Javascript

- Unpacking arrays



C#

- Null coalescing



C++

- Smart pointers

- Pass by value/reference



Notable Mentions

Rust, Kotlin



There are a lot of ideas that went into the design of the language. Some stayed, others were discarded, but we promise not to make Astro a complicated load of incoherent features like C++. But then C++ is a hi-perf systems language, so it has its own value.



Astro goals have been changed several times over the year, cos we don't really have a niche target like most other languages. We just want a nice language that is easy to use and fast to run. But that sounds quite generic, as a result Astro has no concentrated target market. It's in the same camp with Swift. It can be used to write any piece of software, from a website down to an operating system. Of course, you'd need a native compiler implementation of Astro to write an operating system.



As time goes on, we might find the niche we are looking for and stick to that. You are right. Astro is like a nephew to Julia. Astro borrows a good deal of Julia and Python Syntax but it also takes useful concepts from Scala, C#, CLOS, Ruby, Go, Java, etc.Infact there is a short list of where Astro borrowed certain concepts.There are a lot of ideas that went into the design of the language. Some stayed, others were discarded, but we promise not to make Astro a complicated load of incoherent features like C++.But then C++ is a hi-perf systems language, so it has its own value.Astro goals have been changed several times over the year, cos we don't really have a niche target like most other languages. We just want a nice language that is easy to use and fast to run. But that sounds quite generic, as a result Astro has no concentrated target market. It's in the same camp with Swift. It can be used to write any piece of software, from a website down to an operating system. Of course, you'd need a native compiler implementation of Astro to write an operating system.As time goes on, we might find the niche we are looking for and stick to that. 2 Likes

appcypher:



You are right. Astro is like a nephew to Julia. Astro borrows a good deal of Julia and Python Syntax but it also takes useful concepts from Scala, C#, CLOS, Ruby, Go, Java, etc.



Infact there is a short list of where Astro borrowed certain concepts.



Julia

- Multiple dispatch

- AST Macros

- REPL

- Syntax - '<:', '>:', array Indexing, macros, etc.

- Numeric types

- Math-oriented arrays

- Unicode Identifiers



CLOS

- Multiple Inheritance



Python

- Syntax - lists, loops, in, etc.



Jai

- Compile-time execution

- Syntax - generics



Ruby

- Block end punctuation



Crystal

- Sophisticated static type inference



Lua

- List/Dict implementation

- Bytecode representation



Go

- Concurrency model

- Syntax - access modifier blocks, 'func', etc.



Swift's

- Automatic Reference Counting

- Optionals (Nullables)

- Pattern matching

- Syntax - where, let, var, etc.



Scala

#- Match functions #

- Constructor types

- Infix notation

- Singletons



Java

- Anonymous types



Javascript

- Unpacking arrays



C#

- Null coalescing



C++

- Smart pointers

- Pass by value/reference



Notable Mentions

Rust, Kotlin



There are a lot of ideas that went into the design of the language. Some stayed, others were discarded, but we promise not to make Astro a complicated load of incoherent features like C++. But then C++ is a hi-perf systems language, so it has its own value.



Astro goals have been changed several times over the year, cos we don't really have a niche target like most other languages. We just want a nice language that is easy to use and fast to run. But that sounds quite generic, as a result Astro has no concentrated target market. It's in the same camp with Swift. It can be used to write any piece of software, from a website down to an operating system. Of course, you'd need a native compiler implementation of Astro to write an operating system.



As time goes on, we might find the niche we are looking for and stick to that.





Ouch! Bjarne Stroustrup wouldn't like that

Yhup. C++ seems be a bag for almost everyone: the farmer, the hunter, the carpenter, the fisherman, ...

But it barely serves some of them while being great for some others.

Have you checked out D ( Ouch! Bjarne Stroustrup wouldn't like thatYhup. C++ seems be a bag for almost everyone: the farmer, the hunter, the carpenter, the fisherman, ...But it barely serves some of them while being great for some others.Have you checked out D ( Home - D Programming Language ). I might give it a try soon.

Craigston:



Ouch! Bjarne Stroustrup wouldn't like that

Yhup. C++ seems be a bag for almost everyone: the farmer, the hunter, the carpenter, the fisherman, ...

But it barely serves some of them while being great for some others.

Have you checked out D (Home - D Programming Language). I might give it a try soon. Yes, I'm aware of D. We added UFCS to Astro and later found out that D and some other languages use it.



And I actually don't hate C++. I just don't like how I have to keep a lot of wierdness in my brain to command the language successfully. In fact Astro's runtime is written in C++, but we had to replace the interpreter front-end with Python, because we were moving too slow with C++ version.



We probably could use D for the backend, but then D is a managed language, it won't give us the ability to explicitly manage memory resources.



Another language we are currently considering is Rust. For now tho, it's C++ for the runtime, Python for other things. Yes, I'm aware of D. We added UFCS to Astro and later found out that D and some other languages use it.And I actually don't hate C++. I just don't like how I have to keep a lot of wierdness in my brain to command the language successfully.In fact Astro's runtime is written in C++, but we had to replace the interpreter front-end with Python, because we were moving too slow with C++ version.We probably could use D for the backend, but then D is a managed language, it won't give us the ability to explicitly manage memory resources.Another language we are currently considering is Rust. For now tho, it's C++ for the runtime, Python for other things. 2 Likes

this is what i think any serious person wanting to consider the language will ask:

1) Why should i use ur language when there are other languages out there? In other words

what are the compelling objectives of the language?

It's this that are it's unique selling points.

see :

clojure - modern lisp on the jvm, fixed mutable state issues that makes multi threaded programing a pain.

python - easy to write and read.

ruby - fully oop. Make programming fun again

rust - c++ replacement, safer, system level lang etc

lua - very fast small efficient scripting language

erlang - highly fault tolerant. 99.999% uptime!

etc

Astro needs a compelling set of objective(s) to sell. I dont really get what they are.



2) What about libraries

Decent set of libraries to lure developers.

It's new but 2 needs addressing too asap. 2 Likes

asalimpo:

this is what i think any serious person wanting to consider the language will ask:

1) Why should i use ur language when there are other languages out there? In other words

what are the compelling objectives of the language?

It's this that are it's unique selling points.

see :

clojure - modern lisp on the jvm, fixed mutable state issues that makes multi threaded programing a pain.

python - easy to write and read.

ruby - fully oop. Make programming fun again

rust - c++ replacement, safer, system level lang etc

lua - very fast small efficient scripting language

erlang - highly fault tolerant. 99.999% uptime!

etc

Astro needs a compelling set of objective(s) to sell. I dont really get what they are.



2) What about libraries

Decent set of libraries to lure developers.

It's new but 2 needs addressing too asap.



1.) Astro is a modern language that took careful consideration of useful features in several languages.

- It borrowed goroutines for fast, cheap concurrent routines

- It aims to be both compiled to both machine code and bytecode

- It makes OOP a breeze with multiple dispatch and UFCS

- It is maths oriented, this can be seen in its list representation.



In short I would say Astro is a fast embeddable scripting language with modern features. This description does not really represent Astro well, as I've mention earlier on this thread, it is hard to niche Astro, as it can be used for stuffs beyond just scripts or high-level programs. That's why I put in the same camp as Swift. If you check for "the goals of Swift language" then you will know what I'm saying.



I think it is this ubiquity that makes Astro potential, it can be used to write anything from a script down to a kernel. You don't have to switch languages (Python to C) along the way. And with our plans for web assembly target, Astro will have a place in the Web.



2) Libraries (and a package manager) are obviously a planned feature. I've actually started implementing some naive algorithms myself . And for existing libraries, we plan to provide hooks that will allow calling Python and C functions directly. 1.) Astro is a modern language that took careful consideration of useful features in several languages.- It borrowed goroutines for fast, cheap concurrent routines- It aims to be both compiled to both machine code and bytecode- It makes OOP a breeze with multiple dispatch and UFCS- It is maths oriented, this can be seen in its list representation.In short I would say Astro is a fast embeddable scripting language with modern features. This description does not really represent Astro well, as I've mention earlier on this thread, it is hard to niche Astro, as it can be used for stuffs beyond just scripts or high-level programs. That's why I put in the same camp as Swift. If you check for "the goals of Swift language" then you will know what I'm saying.I think it is this ubiquity that makes Astro potential, it can be used to write anything from a script down to a kernel. You don't have to switch languages (Python to C) along the way. And with our plans for web assembly target, Astro will have a place in the Web.2) Libraries (and a package manager) are obviously a planned feature. I've actually started implementing some naive algorithms myself. And for existing libraries, we plan to provide hooks that will allow calling Python and C functions directly.



You have to explain some terms for some of us here , we could wiki or google, but leaving the page to another to look things up is bad ux. psychologically dragging. It's a reason some ppl dont click on links to blogs and essays from here.

The UFCS thing is just greek to me.

The multi dispatch too. I use java, know a little of others, played with go last 2 year so i grok goroutines. But i dont know what the multi dispatch is. Explain using something we oop coders can relate with.

On the github page, i saw no code. I wanted to download and check it out.

Just shed light on some terms that would be greek to us or most of us would be too lazy to research on - even though its just a click away! Humans can be such laazy cats!

Also you have pragmatic understanding of the concepts so you'd be better able to translate it to our understanding..

- Multiple inheritance! ok, it's suppose to be general purpose.You have to explain some terms for some of us here , we could wiki or google, but leaving the page to another to look things up is bad ux. psychologically dragging. It's a reason some ppl dont click on links to blogs and essays from here.The UFCS thing is just greek to me.The multi dispatch too. I use java, know a little of others, played with go last 2 year so i grok goroutines. But i dont know what the multi dispatch is. Explain using something we oop coders can relate with.On the github page, i saw no code. I wanted to download and check it out.Just shed light on some terms that would be greek to us or most of us would be too lazy to research on - even though its just a click away! Humans can be such laazy cats!Also you have pragmatic understanding of the concepts so you'd be better able to translate it to our understanding.. 1 Like 1 Share

From the logo.png, it looks like index starts from 1(not 0). Why?

orimion:

From the logo.png, it looks like index starts from 1(not 0). Why? Astro uses 1-based indexing. Nype feels it's more intuitive, and matches the way we work with maths.



0-based index languages, like C or Python, make you think in offsets of the index rather than the index itself.

Astro - 1 2 3 4 5

[h] [e] [l] [l] [o]

Python - 0 1 2 3 4

Astro -> list[1] = 'h' # returns the element at the actual index

Python -> list[0] = 'h' # returns the element at the offset of the index

Slicing in Astro is more intuitive as a result too.

Astro -> list[2:4] = 'ell' # returns the substrings at the actual indices

Python -> list[1:4] = 'ell' # returns the substrings starting from the offset of

# the first index, but without the offset of the last index

At the end of the day there are both pros and cons for using either methods. We chose intuitiveness. Astro uses 1-based indexing. Nype feels it's more intuitive, and matches the way we work with maths.0-based index languages, like C or Python, make you think in offsets of the index rather than the index itself.Slicing in Astro is more intuitive as a result too.At the end of the day there are both pros and cons for using either methods. We chose intuitiveness. 4 Likes

asalimpo:



The UFCS thing is just greek to me.

The multi dispatch too. I use java, know a little of others, played with go last 2 year so i grok goroutines. But i dont know what the multi dispatch is. Astro has types, they are synonymous with classes in conventional OO languages, except that you can't have functions inside of Astro types. In that sense, they are more like C structs. You only declare fields within a type.



Astro has functions and they are just like C functions.

With these, Astro is able to emphasize the separation between data (types) and operations (functions).



The OO languages you see are usually either completely class based (Java) or a mix of procedures and classes (C++, Python). Astro, however, does OO without using classes. Just types and functions.



The key to achieving this is a delicious mix of Multiple Dispatch and UFCS (Uniform Function Call Syntax)



Multiple Dispatch, simply, is the technique of calling the right function by checking the types of the arguments passed to a function. This definition is not entirely right, but for the sake of this discussion we will go with that.

func add(a = Int, b = Int)

func add(a = Float, b = Float)

If we type add(5, 9), the first function will be called. If we type add(3.5, 1.2), the second function will be called. So the appropriate function is called based on the types of the arguments. This may look like method or function overloading, but it isn't. Multiple dispatch is usually determined at run time and does more than method overloading, like using subtype polymorphism in dispatch process, etc.



With multiple dispatch you can just have only functions and apply them to objects. No need for having methods inside classes.

type Person (name)



type Employee(name, job) <: Person



func details(p = Person):

println(p.name)

You can create an instance of Person and just apply the details function to it.

let daniel = Person("Daniel Okoroha" )

details(daniel) # "Daniel Okoroha"

Because Employee is a subtype of Person, you can also apply details to instances of Employee.

let george = Employee("George Adamu", "Digital Artist" )

details(george) # "George Adamu Digital Artist"

That seems straightforward. So why do we need to define methods then? Well, some may say beacause of dot notation. details is just a function, not a method, you can't do daniel.details(). You can only do details(daniel).



Well that's where UFCS comes in. It's the unification of function syntax with dot notation syntax. Who said we can't use both, huh?

daniel.details() and details(daniel) are valid in Astro.



In essence, this means we can call a function by it's first argument.

So if we can do: play(game, at:"30fps" ). We can also do game.play( at:"30fps" )



And why is using functions only cool?

We can extend a type just by writing a new function for it, even if we inport the type from a foreign module. Methods however can only be written inside their classes.

It also zips the gap between methods and functions. Why should they be treated differently?

It also allows you to focus your attention separately. types contain the data, functions operate on the data. Data vs Operations. Why have operations (methods) inside of data (classes)?



There is a particular function in python that some people have clamored for to be implemented as method.

With Astro, you can use either. It's your choice.

len([1, 2, 3]) or [1, 2, 3].len(). Although in Astro the function is named size.

On the github page, i saw no code. I wanted to download and check it out. We have not made the interpreter's code available for obvious reasons. It's neither complete nor stable. You could get several memory leaks. That's why I tagged it near release. But we can make it available if you don't mind f**king up ur system .

- Multiple inheritance! Yes multiple inheritance . Are you afraid of it? We are not. It's the implementation that matters. Astro has types, they are synonymous with classes in conventional OO languages, except that you can't have functions inside of Astro types. In that sense, they are more like C structs. You only declare fields within a type.Astro has functions and they are just like C functions.With these, Astro is able to emphasize the separation between data (types) and operations (functions).The OO languages you see are usually either completely class based (Java) or a mix of procedures and classes (C++, Python). Astro, however, does OO without using classes. Just types and functions.The key to achieving this is a delicious mix of Multiple Dispatch and UFCS (Uniform Function Call Syntax)Multiple Dispatch, simply, is the technique of calling the right function by checking theof the arguments passed to a function. This definition is not entirely right, but for the sake of this discussion we will go with that.If we type, the first function will be called. If we type, the second function will be called. So the appropriate function is called based on the types of the arguments. This may look like method or function overloading, but it isn't. Multiple dispatch is usually determined at run time and does more than method overloading, like using subtype polymorphism in dispatch process, etc.With multiple dispatch you can just have only functions and apply them to objects. No need for having methods inside classes.You can create an instance of Person and just apply thefunction to it.Because Employee is a subtype of Person, you can also applyto instances of Employee.That seems straightforward. So why do we need to define methods then? Well, some may say beacause of dot notation. details is just a function, not a method, you can't do. You can only doWell that's where UFCS comes in. It's the unification of function syntax with dot notation syntax. Who said we can't use both, huh?andare valid in Astro.In essence, this means we can call a function by it's first argument.So if we can do:. We can also doAnd why is using functions only cool?We can extend a type just by writing a new function for it, even if we inport the type from a foreign module. Methods however can only be written inside their classes.It also zips the gap between methods and functions. Why should they be treated differently?It also allows you to focus your attention separately. types contain the, functionson the data. Data vs Operations. Why have operations (methods) inside of data (classes)?There is a particular function in python that some people have clamored for to be implemented as method.With Astro, you can use either. It's your choice.Although in Astro the function is named size.We have not made the interpreter's code available for obvious reasons. It's neither complete nor stable. You could get several memory leaks. That's why I tagged it near release. But we can make it available if you don't mind f**king up ur systemYes multiple inheritance. Are you afraid of it? We are not. It's the implementation that matters.

The multiple inheritance thing! It's considered bad design practice today. Modern languages are all single inheritance. Reduces complexity.

Maybe it's a fallout of ur c++ roots.





Actually, i think more programming languages will come out nigeria/africa in the future, because i find that as one programs, he tends to write automation scripts which are mini languages. In time, he'll want to know how

actual languages are written. So while we're late to the programming game, with time our maturity will manifest to the world.

Good one Appy. Where can I download and test run the compiler?

asalimpo:

The multiple inheritance thing! It's considered bad design practice today. Modern languages are all single inheritance. Reduces complexity.

Maybe it's a fallout of ur c++ roots.





Actually, i think more programming languages will come out nigeria/africa in the future, because i find that as one programs, he tends to write automation scripts which are mini languages. In time, he'll want to know how

actual languages are written. So while we're late to the programming game, with time our maturity will manifest to the world.

Multiple inheritance is not considered bad design practice, its implementations are.

Many with experience of multiple inheritance will tell you there's nothing wrong with the concept, just the way some languages implement it. C++ is an good example of why people hate multiple inheritance. You hardly hear the same story from people who use Python, Eiffel or CLOS.



And Multiple Inheritance is hard to implement right, so a lot of modern language designers tend to skip it altogether.



Multiple inheritance is super useful when implemented right. It makes OO even easier to reason about. Interfaces, Traits, Mixins and all the other alternatives feel like you have to do extra unintuitive work. Interfaces for example require you to implement methods every time you use it. In fact, the diamond problem still exists with Scala Traits, but the language knows how to handle it properly. In short, it's the implementation that matters.



I would like to have a WorkingStudent type that inherits from both Worker and Student and that's it. I don't care if Worker and Student both inherits from type Person, which results in a diamond problem. And I don't want to manually reimplement methods with every inheritance.



There! You need multiple Inheritance. Multiple Inheritance allows reuse of code. Multiple inheritance is not considered bad design practice, its implementations are.Many with experience of multiple inheritance will tell you there's nothing wrong with the concept, just the way some languages implement it. C++ is an good example of why people hate multiple inheritance. You hardly hear the same story from people who use Python, Eiffel or CLOS.And Multiple Inheritance is hard to implement right, so a lot of modern language designers tend to skip it altogether.Multiple inheritance is super useful when implemented right. It makes OO even easier to reason about. Interfaces, Traits, Mixins and all the other alternatives feel like you have to do extra unintuitive work. Interfaces for example require you to implement methods every time you use it. In fact, the diamond problem still exists with Scala Traits, but the language knows how to handle it properly. In short, it's the implementation that matters.I would like to have atype that inherits from bothandand that's it. I don't care ifandboth inherits from type, which results in a diamond problem. And I don't want to manually reimplement methods with every inheritance.There! You need multiple Inheritance. Multiple Inheritance allows reuse of code. 1 Like

Emmach10:

Good one Appy. Where can I download and test run the compiler? It's not available to the public yet. It's not available to the public yet.

I think those who've used multiple inheritance can vouch for it. I heard a c++ programmer who said java was rubbish (back in the day though).

But the industry is moving away from it. It was drummed into me through many java authors that multiple inheritance and goto is bad.

The problem with multiple inheritance is that one could betaking in far more than is necessary.

Inheriting and having access to all the codes in a higher heirarchy is in the least, philosophical impure.

So we're back to square one. Both approaches have major flaws.

A programmer could inherit from a class where he needs just one method, but gets exposed to

so many methods and client programmers using his code could exploit that access.

With interfaces, its cumbersome to implement unnecessary methods - but interfaces could be finetuned

such hat clients implements those that reduce boiler plates.



Anyway, since its all about where to move methods to in a parent class, can't he artificiality of enforced contracts in interfaces be solved by simple creating smarter interface objects? One in which methods that dont need to be implemented in sub classes can be made. I think java 8 has something like this. If it happens then,

the same things multiple inheritance seeks to accomplish will be achievable in single inheritance languages.

But be it as it may, with more power comes more complexity.



The 1 based indexing seems due anyway. It's one area noobs always get stumped when learning programming.

asalimpo:

I think those who've used multiple inheritance can vouch for it. I heard a c++ programmer who said java was rubbish (back in the day though).

But the industry is moving away from it. It was drummed into me through many java authors that multiple inheritance and goto is bad.

The problem with multiple inheritance is that one could betaking in far more than is necessary.

Inheriting and having access to all the codes in a higher heirarchy is in the least, philosophical impure.

So we're back to square one. Both approaches have major flaws.

A programmer could inherit from a class where he needs just one method, but gets exposed to

so many methods and client programmers using his code could exploit that access.

With interfaces, its cumbersome to implement unnecessary methods - but interfaces could be finetuned

such hat clients implements those that reduce boiler plates.



Anyway, since its all about where to move methods to in a parent class, can't he artificiality of enforced contracts in interfaces be solved by simple creating smarter interface objects? One in which methods that dont need to be implemented in sub classes can be made. I think java 8 has something like this. If it happens then,

the same things multiple inheritance seeks to accomplish will be achievable in single inheritance languages.

But be it as it may, with more power comes more complexity.



The 1 based indexing seems due anyway. It's one area noobs always get stumped when learning programming. I like your argument.

There are truly camps for and against Multiple Inheritance and it is true that modern languages are moving away from it. Language moving away from old concepts and adopting it back is nothing new tho. Multiple dispatch was implemented in Lisp but never got wide-scale adoption afterwards. Julia took the concept and polished it, which is why Astro is adopting it.



MI is already designed into the language, removing it will need thorough planning for an alternative. Maybe in the future when there is a convincing proposal for why Astro should use some other Inheritance mechanism, then MI can be replaced in Astro.



I believe you are pragmatic, so philosophical impurity can only be determined by how well a concept works in practice. Let's see how MI fairs with the language first. If it proves unusable or bad, we will consider an alternative. I like your argument.There are truly camps for and against Multiple Inheritance and it is true that modern languages are moving away from it. Language moving away from old concepts and adopting it back is nothing new tho. Multiple dispatch was implemented in Lisp but never got wide-scale adoption afterwards. Julia took the concept and polished it, which is why Astro is adopting it.MI is already designed into the language, removing it will need thorough planning for an alternative. Maybe in the future when there is a convincing proposal for why Astro should use some other Inheritance mechanism, then MI can be replaced in Astro.I believe you are pragmatic, so philosophical impurity can only be determined by how well a concept works in practice. Let's see how MI fairs with the language first. If it proves unusable or bad, we will consider an alternative. 1 Like

Hmm, this is a very interesting development, but i cant say much till we've been able to write some code for the interpreter to run, but BIG KUDOS to you guys for even attempting something like this, so how do you generate machine code, LLVM backend ?

stack1:

Hmm, this is a very interesting development, but i cant say much till we've been able to write some code for the interpreter to run True. We are actively working on that.

, but BIG KUDOS to you guys for even attempting something like this, so how do you generate machine code, LLVM backend ? We are working on just the interpreter now. LLVM is planned for the future. True. We are actively working on that.We are working on just the interpreter now. LLVM is planned for the future. 1 Like

My opinion is that in fields like these, they're no resources that can guide the curious and interested into learning steps of how its done. The dragon book has been criticized as being hard to read without math background. The entire process is made to look more complex than it is. Thanks to the community around it.

Mathematics for this very reason is archaic and needs an overhawl of its syntax,which is ugly and unfriendly.

I know it's a tall task but if you look at the trends of successful languages, you find that the familiar, e.g python, win market share over the unfamiliar. Just because of their syntax.

Just my rant, though.

asalimpo:



My opinion is that in fields like these, they're no resources that can guide the curious and interested into learning steps of how its done. The dragon book has been criticized as being hard to read without math background. The entire process is made to look more complex than it is. Thanks to the community around it.

Mathematics for this very reason is archaic and needs an overhawl of its syntax,which is ugly and unfriendly.

I know it's a tall task but if you look at the trends of successful languages, you find that the familiar, e.g python, win market share over the unfamiliar. Just because of their syntax.

Just my rant, though. The thing is Astro is not Python. The design goals of python are different; to be simple and expressive. Astro chooses intuitiveness and saving programmers time. Redundancy is good in some cases, in some other, Astro makes it optional.



Familiarity is also relative. Imperative guys will see Python as familiar. Functional folks will think Erlang familiar and scientific (Matlab and co.) people will find Julia syntax familiar. Astro is more in the imperative camp with a touch of functional and scientific.

We are not really competing for market share here; just ideas that can make some parts of coding intuitive and easier.



Astro syntax is not even that new. I believe polyglots should find it familiar and, with introduction to certain concepts, should be able to command the language well.



Designing a language is freaking far from easy! We wanted it to look very Pythonic in the beginning, but syntactical tradeoffs had to be made for some concepts (that are not in Python) to make sense. We can't betray intuitiveness just because we want it to look absolutely like Python. Even Nim and Crystal couldn't do that.



So maybe Astro is not for everyone looking for familiarity, but it's definitely for people looking to try out new things; new concepts that might make their coding lifes easier. The thing is Astro is not Python. The design goals of python are different; to be simple and expressive. Astro chooses intuitiveness and saving programmers time. Redundancy is good in some cases, in some other, Astro makes it optional.Familiarity is also relative. Imperative guys will see Python as familiar. Functional folks will think Erlang familiar and scientific (Matlab and co.) people will find Julia syntax familiar. Astro is more in the imperative camp with a touch of functional and scientific.We are not really competing for market share here; just ideas that can make some parts of coding intuitive and easier.Astro syntax is not even that new. I believe polyglots should find it familiar and, with introduction to certain concepts, should be able to command the language well.Designing a language is freaking far from easy! We wanted it to look very Pythonic in the beginning, but syntactical tradeoffs had to be made for some concepts (that are not in Python) to make sense. We can't betray intuitiveness just because we want it to look absolutely like Python. Even Nim and Crystal couldn't do that.So maybe Astro is not for everyone looking for familiarity, but it's definitely for people looking to try out new things; new concepts that might make their coding lifes easier. 1 Like

appcypher:



The thing is Astro is not Python. The design goals of python are different; to be simple and expressive. Astro chooses intuitiveness and saving programmers time. Redundancy is good in some cases, in some other, Astro makes it optional.



Familiarity is also relative. Imperative guys will see Python as familiar. Functional folks will think Erlang familiar and scientific (Matlab and co.) people will find Julia syntax familiar. Astro is more in the imperative camp with a touch of functional and scientific.

We are not really competing for market share here; just ideas that can make some parts of coding intuitive and easier.



Astro syntax is not even that new. I believe polyglots should find it familiar and, with introduction to certain concepts, should be able to command the language well.



Designing a language is freaking far from easy! We wanted it to look very Pythonic in the beginning, but syntactical tradeoffs had to be made for some concepts (that are not in Python) to make sense. We can't betray intuitiveness just because we want it to look absolutely like Python. Even Nim and Crystal couldn't do that.



So maybe Astro is not for everyone looking for familiarity, but it's definitely for people looking to try out new things; new concepts that might make their coding lifes easier.

I wasnt criticizing Astro's syntax in that rant. But rather the fact that some resources are not accessible to people who are interested because of some unnecessary barriers which turns off the uninitiated. I was talking about compilers and such books and stuffs. And stating my opinion on mathematics too, there have this artificial stiffness that people in the community (academics) feel have to be maintained to preserve that aura of mystery about the field. It's the same thing with the legal profession too. It was a general rant not directed at your language and syntax at all. We'd discussed that earlier b4. Actually i'm a fan of keep it ultra simple. And to do these, new concepts should be marketed in the symbols the uninitiated are already familiar with. That's y, python, presented in english-like syntax, is approachable to people new to programming.

And y maths is 'hard' because, i believe, wen thinking on a problem, the syntax could get in the way.

But's its all a philosophical rant,not a bash or critique at Astro, though i had previously critiqued it on that ground. I wasnt criticizing Astro's syntax in that rant. But rather the fact that some resources are not accessible to people who are interested because of some unnecessary barriers which turns off the uninitiated. I was talking about compilers and such books and stuffs. And stating my opinion on mathematics too, there have this artificial stiffness that people in the community (academics) feel have to be maintained to preserve that aura of mystery about the field. It's the same thing with the legal profession too. It was a general rant not directed at your language and syntax at all. We'd discussed that earlier b4. Actually i'm a fan of keep it ultra simple. And to do these, new concepts should be marketed in the symbols the uninitiated are already familiar with. That's y, python, presented in english-like syntax, is approachable to people new to programming.And y maths is 'hard' because, i believe, wen thinking on a problem, the syntax could get in the way.But's its all a philosophical rant,not a bash or critique at Astro, though i had previously critiqued it on that ground.

asalimpo:





I wasnt criticizing Astro's syntax in that rant. But rather the fact that some resources are not accessible to people who are interested because of some unnecessary barriers which turns off the uninitiated. I was talking about compilers and such books and stuffs. And stating my opinion on mathematics too, there have this artificial stiffness that people in the community (academics) feel have to be maintained to preserve that aura of mystery about the field. It's the same thing with the legal profession too. It was a general rant not directed at your language and syntax at all. We'd discussed that earlier b4. Actually i'm a fan of keep it ultra simple. And to do these, new concepts should be marketed in the symbols the uninitiated are already familiar with. That's y, python, presented in english-like syntax, is approachable to people new to programming.

And y maths is 'hard' because, i believe, wen thinking on a problem, the syntax could get in the way.

But's its all a philosophical rant,not a bash or critique at Astro, though i had previously critiqued it on that ground. Oh, sorry I misinterpreted you.

Yeah, the Dragon Book is quite heavy, and picks up complex concepts rather fast. My own problem is with the length. I got tired reading it, but I revisit it once in a while to understand certain things better. But the ultimate resource that got me on my feet quick is

As for maths syntax, I don't think it is that bad. I definitely don't want to be typing 1 plus 1 minus 5. There is a point where simplicity becomes a hinderance, and there is a point where terseness becomes terrible.

I'm more critical of how mathematical concepts are explained in traditional educational system. No practicality, just bunch of abstract concepts to memorize.



I welcome critiques on Astro tho, don't let my previous reply deter you from assessing Astro. Oh, sorry I misinterpreted you.Yeah, the Dragon Book is quite heavy, and picks up complex concepts rather fast. My own problem is with the length. I got tired reading it, but I revisit it once in a while to understand certain things better. But the ultimate resource that got me on my feet quick is this youtube tutorials As for maths syntax, I don't think it is that bad. I definitely don't want to be typing. There is a point where simplicity becomes a hinderance, and there is a point where terseness becomes terrible.I'm more critical of how mathematical concepts are explained in traditional educational system. No practicality, just bunch of abstract concepts to memorize.I welcome critiques on Astro tho, don't let my previous reply deter you from assessing Astro. 1 Like

At first, I was understanding the comments. Now, I don't know if I understood what I taught I understand.



A very good one for the initiative.



As Astro gotten to the production level? I meant if it can be used in creating some apps right away.



If yes, are there any tutorials that introduces the Lang? Majority won't want to know the cores the thread has been discussing at first... Maybe later.



As Asalimpo has said, you may need to leap back and talk more on what makes astro better rather than the generics.



Nice one again!

appcypher:



Oh, sorry I misinterpreted you.

Yeah, the Dragon Book is quite heavy, and picks up complex concepts rather fast. My own problem is with the length. I got tired reading it, but I revisit it once in a while to understand certain things better. But the ultimate resource that got me on my feet quick is this youtube tutorials.

As for maths syntax, I don't think it is that bad. I definitely don't want to be typing 1 plus 1 minus 5. There is a point where simplicity becomes a hinderance, and there is a point where terseness becomes terrible.

I'm more critical of how mathematical concepts are explained in traditional educational system. No practicality, just bunch of abstract concepts to memorize.



I welcome critiques on Astro tho, don't let my previous reply deter you from assessing Astro.

We're behind you. On the math rant though, i still think the mathematics community has done the entire world a great disservice by their arcane syntax. since words are labels on concepts, abbreviation can be

introduced when the concept is understood. Infact, that's how our minds work. e.g

internet acronyms like, AFAIK, IOW, TL;DR etc. are abbreviations that map directly to the words used to

create the concepts. It's so intuitive creating directly mapping abbreviations that our minds expand them

subconciously without conscious effort. It's this thing, that i think should be introduced to artificial languages so that pontentially great prospect can enter the field and not get turned off by the barriers .

e.g

in maths,

the symbolism for summation packs multiple concepts into 1! How intuitive is that!

Sigma does in one symbolic representation what a for loop does in programming languages. I could on.

Yeah, the maths community accepts this but overall. Maths does needs overhauling at the syntatic level.

The same thinking process used for programming is the same used in mathematics, but why is programming more addictive to people yet maths a put off? There's the instant feedback factor of programming, but ruling that out, it's the approachability of newer languages. And these so called newer languages are drawing market share because of familiar symbolism. Wonder y people find c,c++ , perl had? A terse page of them and subconsciously the reader is turned off. Fear sets in. He backs away! How many people back away from a newspaper headline?

Just a rant anyway. We're behind you. On the math rant though, i still think the mathematics community has done the entire world a great disservice by their arcane syntax. since words are labels on concepts, abbreviation can beintroduced when the concept is understood. Infact, that's how our minds work. e.ginternet acronyms like, AFAIK, IOW, TL;DR etc. are abbreviations that map directly to the words used tocreate the concepts. It's so intuitive creating directly mapping abbreviations that our minds expand themsubconciously without conscious effort. It's this thing, that i think should be introduced to artificial languages so that pontentially great prospect can enter the field and not get turned off by the barriers .e.gin maths,the symbolism for summation packs multiple concepts into 1! How intuitive is that!Sigma does in one symbolic representation what a for loop does in programming languages. I could on.Yeah, the maths community accepts this but overall. Maths does needs overhauling at the syntatic level.The same thinking process used for programming is the same used in mathematics, but why is programming more addictive to people yet maths a put off? There's the instant feedback factor of programming, but ruling that out, it's the approachability of newer languages. And these so called newer languages are drawing market share because of familiar symbolism. Wonder y people find c,c++ , perl had? A terse page of them and subconsciously the reader is turned off. Fear sets in. He backs away! How many people back away from a newspaper headline?Just a rant anyway. 1 Like

tohero:

At first, I was understanding the comments. Now, I don't know if I understood what I taught I understand.



A very good one for the initiative.



As Astro gotten to the production level? I meant if it can be used in creating some apps right away.



If yes, are there any tutorials that introduces the Lang? Majority won't want to know the cores the thread has been discussing at first... Maybe later. Its interpreter hasn't been released yet so it's not production-ready, and probably won't be for a while after release.

It's certain we'll have a lot of bugs to fix when user reports start streaming in.

After the interpreter design has been finalized, we will move on to machine code compilation with LLVM.

As Asalimpo has said, you may need to leap back and talk more on what makes astro better rather than the generics.



Nice one again! I think I've touched some parts that makes Astro different from other language in previous comments.

Lemme put it thus, to make it clearer for people who have the same question.

Astro is an object-oriented multi-paradigm scripting language that brings with it the benefits a static type system (looks like Python, moves like Java).

Astro also introduces an new intuitive way of doing OOP (using Multipe Dispatch and UFCS) and maintains a design consideration to make technical computing easy.



Astro ≈ Julia + Crystal + Nim Its interpreter hasn't been released yet so it's not production-ready, and probably won't be for a while after release.It's certain we'll have a lot of bugs to fix when user reports start streaming in.After the interpreter design has been finalized, we will move on to machine code compilation with LLVM.I think I've touched some parts that makes Astro different from other language in previous comments.Lemme put it thus, to make it clearer for people who have the same question.Astro is an object-oriented multi-paradigm scripting language that brings with it the benefits a static type system (looks like Python, moves like Java).Astro also introduces anintuitive way of doing OOP (using Multipe Dispatch and UFCS) and maintains a design consideration to make technical computing easy.Astro ≈ Julia + Crystal + Nim



var appcypher = Str reads better as "variable appcypher equals a string". Somehow, I like it that way for declarations. But I'm comfortable with other styles too so I'm not trying to nitpick.

I see Astro supports list unpacking too; I've always loved it in Python.

On line 18 of the screenshot, you accessed more than one property of the 'facelessManipulator' type (object?) without repeating the type name. Nice syntactic sugar there.

Can you explain how inheritance works in Astro? It seems one can define certain members to inherit from a super type (line 13) without relying on member scope (public, private, or protected).



That logo in the terminal is so Juliac

Is that the atom editor? From the screenshot you shared, I find the syntax of Astro quite intuitive. For instance, in variable declaration,reads better as "variable appcypher equals a string". Somehow, I like it that way for declarations. But I'm comfortable with other styles too so I'm not trying to nitpick.I see Astro supports list unpacking too; I've always loved it in Python.On line 18 of the screenshot, you accessed more than one property of the 'facelessManipulator' type (object?) without repeating the type name. Nice syntactic sugar there.Can you explain how inheritance works in Astro? It seems one can define certain members to inherit from a super type (line 13) without relying on member scope (public, private, or protected).That logo in the terminal is so JuliacIs that the atom editor?

Craigston:

From the screenshot you shared, I find the syntax of Astro quite intuitive. For instance, in variable declaration,

var appcypher = Str reads better as "variable appcypher equals a string". Somehow, I like it that way for declarations. But I'm comfortable with other styles too so I'm not trying to nitpick.

I see Astro supports list unpacking too; I've always loved it in Python.

On line 18 of the screenshot, you accessed more than one property of the 'facelessManipulator' type (object?) without repeating the type name. Nice syntactic sugar there.

Can you explain how inheritance works in Astro? It seems one can define certain members to inherit from a super type (line 13) without relying on member scope (public, private, or protected). I see you took some of your time to study the little details I've left so far. I truly appreciate that.

Astro uses a Multiple inheritance model just like Python.

type Monkey

type Bird

type FlyingMonkey <: Monkey, Bird

You can also have abstract types by adding 'ab' to your type declaration. This simply means the type cannot be instantiated.

type ab Person

let person = Person # error! type Person is an abstract type and cannot be instantiated.

Abstract types are useful for a lot of things. It can allow us to implement Java interfaces for example.



There are access modifiers in Astro, tho not as elaborate as Java's.

Astro has hide modifiers for fields. Hide is synonymous with protected in Java. It means such fields can only be seen and referenced by the type's (or subtype's) constructors and their associated functions.

type Account

let .password = Int # the dot signifies hidden access

Contents of a module (also a file) are public by default. You can make a module primitive private to prevent other modules from seeing or referencing it.

let `rent = 30_000 # the back tick signifies private access

Astro doesn't have package-level access. Nypro claims it is used less in practice and that Java has it because it allows just one class per file. If we see the need for it we will consider having it in Astro.

That logo in the terminal is so Juliac Astro's REPL is inspired by Julia's.

Is that the atom editor? Yes, it's an Atom editor. We are implementing the IDE on Atom. Nypro also wrote some Astro plugins for Sublime Text, Vim and IntelliJ, but Atom is our main focus. I see you took some of your time to study the little details I've left so far. I truly appreciate that.Astro uses a Multiple inheritance model just like Python.You can also have abstract types by adding 'ab' to your type declaration. This simply means the type cannot be instantiated.Abstract types are useful for a lot of things. It can allow us to implement Java interfaces for example.There are access modifiers in Astro, tho not as elaborate as Java's.Astro has hide modifiers for fields. Hide is synonymous with protected in Java. It means such fields can only be seen and referenced by the type's (or subtype's) constructors and their associated functions.Contents of a module (also a file) are public by default. You can make a module primitive private to prevent other modules from seeing or referencing it.Astro doesn't have package-level access. Nypro claims it is used less in practice and that Java has it because it allows just one class per file. If we see the need for it we will consider having it in Astro.Astro's REPL is inspired by Julia's.Yes, it's an Atom editor. We are implementing the IDE on Atom. Nypro also wrote some Astro plugins for Sublime Text, Vim and IntelliJ, but Atom is our main focus. 1 Like

nice work but c pointer rules no pointer no coding