Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have been a searching for alternative to Moose (Modern object-oriented Perl)
Because Moose is slow I have seen several post relation to this issue, I not want that.
Example from the same creator: https://www.youtube.com/watch?v=ugEry1UWg84&feature=youtu.be&t=260
So I found this alternative from the same creator of moose:
https://metacpan.org/pod/MOP#DESCRIPTION
MOP - A Meta Object Protocol for Perl 5
This module implements a Meta Object Protocol for Perl 5 with minimal overhead and no non-core dependencies (eventually).
Work with UNIVERSAL::Object:
https://metacpan.org/pod/UNIVERSAL::Object
Is this a good choice and alternative to Moose, does someone test this software ?
Related post:
https://www.perlmonks.org/?node_id=1220917
Thanks.
Note: I forget to mention I know about Moo, Mouse, etc, maybe exist something better ?
MOP is very low level, Moxie is based on it; but it's still a proof of concept.
There are faster and lighter alternatives that have been tested in production: Moo and Mouse.
In which context do you use Moose and find it slow ? There is of course an overhead involved, but most of it happens at startup time (compilation) ; then, at runtime, most features are cheap (as long as you make your classes immutable), as explained in the documentation. Over the time Moose has become the de facto standard for object oriented programming and it has a very, very wide ecosystem (a search on MooseX on metacpan returns 820 results). Don't give up on it to early.
If you really need faster startup time (like in vanilla CGI environment for example), the most relevant alternative to Moose is Moo, Minimal Object Orientation. It is really light-weithg, has no XS dependency, while implementing a significant subset of Moose (also, its syntax is fully compatible with Moose so you upgrade to Moose anytime later if you need some piece of functionality that you find missing in Moo). It also has a rich ecosystem.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I read the wonderful blog from JOHN A DE GOES regarding to tagless final. In the section 5.Fake Abstraction, he has mentioned:
Unfortunately, these operations satisfy no algebraic laws—none
whatsoever! This means when we are writing polymorphic code, we have
no way to reason generically about putStrLn and getStrLn.
For all we know, these operations could be launching threads, creating
or deleting files, running a large number of individual side-effects
in sequence, and so on.
He is correspond to the following tagless algebra:
trait Console[F[_]] {
def putStrLn(line: String): F[Unit]
val getStrLn: F[String]
}
Does it mean, writting laws for tageless algebra is not possible or do I misunderstand something.
A few things:
John A De Goes, while is very knowledgeable has also a lot of opinions and express them as if they were inferred from mathematics without making a clear distinction - this posts is a part of series where he basically pitches that tagless final is often a bad solution and ZIO is a good one
paragraph says that tagless final often doesn't follow algebraic laws which means that we cannot e.g. consider IO monid/semigroup and similar. Which is true. But it doesn't mean that these constructs cannot obey some contracts (called laws) because the do and that is the whole point of Cats Effect
nobody can force you to write laws for algebras, because laws are basically some particular way of writing specification/tests where you write a separate test for some class of interfaces and then for every implementation you can instantiate this test to check if your implementation fulfill contracts - and yes, nobody can force you to write test for your code. However, that can be said about virtually everything we code, and TTFI give you benefit of making it easier to specify a common behavior of widely different implementations, and then writing your code and tests carefully, sticking to the part of contract that is vital for a particular piece of code while also making these dependencies on contracts explicit
So yes, nobody can force you to write laws for your algebras, but people who implement them in libraries actually do this, and if you write your own algebras, you are encouraged to do so, so this argument is stretched and eristic.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
We are using Perl extensively in our project which is used to fetch the data from DB and install several components. Now we want to upgrade it to 5 from 4.2. I would like to know what changed and what are features that the latest Perl version has over 4.2. Someone please guide me to get this done.
Some things perl4 didn't have:
local (lexically scoped) variables
data structures (beyond simple arrays-of-scalars and hashes-of-scalars)
references (including references to subroutines, which let you abstract over behavior)
closures / first-class functions
OO: classes, methods, and objects
a module system, and a way to implement parts or all of a module in C, letting you bind to external libraries
CPAN: a central repository for modules written by other people for almost any task you can think of (current count: 188,959 modules)
pragmas that can warn you about or disable dangerous and questionable operations (use strict, use warnings)
Unicode support (in strings + all core operations; encoding layers in file handles)
subroutines that can be called like (most) builtins (& and parentheses not required, special calling conventions can be enabled by using "prototypes")
tie: a variable (scalar/array/hash) can be backed by an object; operations on the variable automatically invoke methods on the object instead
threads
overridable keywords
exception handling with die/eval {}
tons and tons of regex enhancements
... and hundreds of things I don't remember and can't list here. Seriously, perl5 is a very different language from perl4, even if many perl4 features are still there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm pretty much a noob with Unity. As a c++ programmer, the naming conventions in Unity bothers me a little. And having OCD ontop of that makes me go crazy ;)
The objects has say a property Transform which again has a property Position.
But these properties must be accessed by writing transform.position in the code using lower case. This is not very intuitive to me. So I wonder how I can look at it in order to more easily avoid complications. And what conventions I should use to be able to tell everything appart by taking a quick look at the variables.
The Unity convention is actually rather simple: everything is Pascal-cased, types (classes, structs, enums) and methods start with upper-case, fields and properties with lower-case. Enum values in upper-case, constants in lower-case (usually).
So ClassName, MethodName, myField, myProperty { get; set; }, MyEnum.CaseA... that's it.
As for your example, Transform is a class, whereas transform is an accessor to the instance of Transform in that particular GameObject/Component.
Also, Transform doesn't have a Position property, it has a position property (always lower-case).
This is more or less based on C#'s conventions and the standard .NET library (MS has very precise guidelines about it), except standard .NET uses UpperCase for public/protected methods AND properties, and lower-case for private (again, usually; what's private is more left to the taste of the coder I think).
As a side-note, with any codebase, in any language, the best way is ALWAYS to follow the existing convention. Every seasoned programmer will tell you this. I understand about OCD, believe me, but in this case I suggest you let it go.
There are very little objective arguments as to why a convention would be better than another (by definition a convention is arbitrary), and even if there was, the absolute worse thing you can do is mix several conventions, because then you have 0 convention at all and never know what to expect.
At least C# tries to standardize; I've worked on several C++ codebases and I fail to see a common denominator: UpperCaseClassNames, lowerCaseClassNames, underscore_separated, tClassName, ENUMS_IN_UPPER, or not... it's rarely consistent, so the less you mix the better.
I am trying to use a Perl API that has been written to use the Moose OO system but there is absolutely no inheritance, aggregation, or composition involved between the objects.
And, apart from a single optional role for debugging, there are no roles or mixins involved as well.
As far as I can see at the moment, using Moose just seems to add a massive amount of complication and compile-time overhead for very little benefit.
Why would you use Moose, or OO, as a simple method of encapsulation instead of using the far simpler technique of packaging the code into Perl modules?
Just to clarify, I am totally convinced of the many advantages of using Moose to do OO in Perl correctly and completely. I just don't understand why use OO at all as a simple encapsulation technique? I am not after a subjective argument in favour or otherwise of Perl OO. I am hoping that I am missing some advantage to using the OO paradigm here that I am simply not seeing atm.
This question has an excellent series of points about data encapsulation in Perl. N.B. I am not talking about enforced encapsulation where the system stops you from looking where you shouldn't, more about just only exposing methods in a package that manipulate the data you want to play with.
Is there some advantage to using OO here that I am missing?
Edit 1: After a bit of detective work, I have just seen that the author of the Perl API is also heavily involved in the maintenance and support of the Moose framework.
Edit 2: I have just seen this question which asks a similar thing from a slightly different angle. It's seems like my answer is actually "why would you want to add the complication in the first place?", especially given the info in edit 2 above.
POSSIBLE ANSWER
The API in question seems to be only using the Moose OO system in order to prevent namespace pollution.
This could also be done more than adequately by using Perl packages though, as #amon point out in the comment below, using the standard package mechanism can become cumbersome quite quickly. BTW A big thanks to for all the comments to help clarify what I was asking.
Every situation is diffferent, and whether you choose to use Moose or another object framework (or none at all) really comes down to what you're planning to do and what your requirements are.
There might not be any immediate advantage to writing the system in question with Moose, but consider these:
You get free access to Moose's metaobject system, so you can interrogate the objects for useful information in a well-defined way
You can extend the provided classes using Moose's inheritance system; so even if they don't use inheritance themselves, the framework is already in place for you to do so if needed
You have peace-of-mind because you know the system was built on the most widely-deployed and well-tested object framework for Perl.
People know Moose, meaning there is a higher probability of getting answers to questions if something breaks.
IOW, there is inherent value in using popular tools.
Not sure it's relevant to the API in question, but no-one seems to have mentioned data types yet - that's a big benefit of Moose or Moo, having easily defined and understood (and re-usable) type validation and coercion for attributes.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am absolutely happy with Scala and just love it :)
But sometimes I really want to go a bit more "low level", without a JVM and using "cool" CPU-Features like SSE etc.
So what would be a good second language besides Scala?
It should be:
Compiled to machine code
Easy usage of C-libraries
Possible to program very close to the hardware
Possible to program in a very highlevel-way when I want to
So basically I want a Scala where I can just throw in inline assembler when I want to :) I assume, that such a language does not exist, but maybe there are some that come close.
So what would be a good choice?
C++?, D?, OCaml?
I programmed a bit in C++ (15 Years ago) and very little with OCaml. In both cases, I only solved a few problems and never got very "deep" into the language itself.
You're pretty much describing D.
Compiled to machine code: Check. There is an experimental .NET VM implementation, but all three major implementations (DMD, LDC, GDC) compile directly to native code and the language is designed to make native compilation feasible.
Easy usage of C libraries: D supports the C ABI and all C types. Pretty much all you have to do is translate the header file and link in the C object file. This can even be partially automated.
Possible to program very close to the hardware: Check. D is what I'd call an idiomatic superset of C. It does not support every piece of C syntax, its module system is completely different, static arrays are value types in D2, etc. However, for any construct in the C language proper (i.e. excluding the preprocessor) there is an equivalent construct in D or the standard library. For any piece of C code (excluding preprocessor abuse) there is a canonical D translation that looks roughly the same and should generate the same assembly language instructions if you're using the same compiler backend. In other words, every C idiom (excluding preprocessor abuse) can be translated to D in a straightforward way.
The reference implementation of D also supports inline ASM, so you can mess with SSE, etc.
Possible to program in a very highlevel-way when I want to: Check. D is designed to be primarily garbage-collected language (though you can use manual memory management if you insist and are careful not to use library/runtime features that assume GC). Other than that, high-level programming is mostly implemented via template metaprogramming. Before you run away, please understand that template metaprogramming in D is greatly improved compared to C++. Doing template metaprogramming in D vs. C++ is like doing object oriented programming in C++ vs. C. In D template metaprogramming is designed into the language, whereas in C++ there are just enough features that you can use clever hackishness to make it barely work. The same could be said for object-oriented programming in C++ vs. C. The std.algorithm and std.range modules of Phobos are good examples of the high-level subset of D.
Here are some that satisfy the criteria mentioned in your question:
BitC
Clay
D
Rust
Go
I'm thinking about this, too, as I'm currently doing a C project and feeling very unproductive, also missing Scala. (I also did a lot of C++ in the Pleistocene...) I may switch to go. D also looks attractive.
Another option, if it makes sense for the problem, is to use C + a scripting language, like Lua or Ruby. It's what Unix+shells and emacs have done forever. You get performance and low-level bit twiddling when you need it and productivity when that's more important.
C++0X, Erlang and maybe Haskell and Go. C++ and Erlang has a strong user base and there is many jobs avaliable with C++0x and Erlang. (I am uncertain how good the C/C++ interop is with Go)
C++0X ("cee plus plus oh ex") is a good option. It has lamda functions and other good stuff.
Walktrough of C++0X TechDays 2010: Modern Programming with C++0x
Also C++0X has good Generics support as documented in Type Classes as Objects and Implicits, Oliviera, Moors, Odersky, OOPSLA 2010. See their Figure 12 below:
Something that fits your requirement is C/C++, as you can inline assembly language with regular code. Calling C libraries will be natural :)
Another thing that fits is the HLA implementation of assembly language (wiki article here) - it is assembly with a lot of high level constructs to make things easier (and faster) for beginners to learn (it compiles to "proper" native code).
Like D and BitC, ooc (http://www.ooc-lang.org/) has a lot of features that appeal to a Scala (or Haskell) fan.
I think Nimrod is also a valid candidate here based on your requirements.
You should take a look at Go.
It's still very new, but take a look at Vala. It's a sweet layer of syntactic frosting upon the GObject cake and compiled to pure C.
It supports features like closures and limited type inference.
Think about using C or C++ for the very lowest level programming, and then wrapping that with JNI or JNA in a Scala library. In some cases, you can have your cake and eat it too this way.