Sure, it is not needed, we can always write things in a different way. As a matter of fact, with such an argument, hardly any improvement should be accepted.

In comparison, Perl/Python/Javascript, which also have the latter property, have other false-like values (0 and empty string), which make || differ from a null-coalescing operator in many more cases (numbers and strings being two of the most frequently used data types). This is what led Perl/Python/Javascript to add a separate operator while Ruby hasn't.

Examples by languages

One language that is currently being developed, Rascal, takes a hybrid approach allowing dynamic typing within functions but enforcing static typing for the function signature.

When a language presumes to know more than its user, that's when there's trouble.

Just because a language has a feature that might be dangerous doesn't mean it's inherently a bad thing. When a language presumes to know more than its user, that's when there's trouble.

I'd argue that when you find a programming language devoid of danger, you've found one that's not very useful.

The reason eval is there is because when you need it, when you really need it, there are no substitutes. There's only so much you can do with creative method dispatching, after all, and at some point you need to execute arbitrary code.

I think "purely functional, not a single re-assigned variable" often introduces significant extra complexity, when Ruby is a language that embraces both functional and imperative programming.

One of my favorite aspects of Ruby is how easy it is to write in a functional programming style, and including the scan operation would expand the number of use cases covered by functional methods.

TypeScript offers special syntax for turning a constructor parameter into a class property with the same name and value. These are called parameter properties

yield is a bit of laguage level magic that only works in the context of a method.

2 • 3 = 6

Ideally we could use Unicode, 3 2 1 ~ 3 2 1 ≃

I have been doing different things w/ Ruby for a couple of years now and the only bad thing I can say about it is that it makes programming in other languages feel awfully burdensome. = )

For example, whereas C programmers have argued for years about where to put their brackets, and whether code should be indented with tabs or spaces, both Rust and Go eliminate such issues completely by using a standard formatting tool (gofmt for Go, rustfmt for Rust) which rewrites your code automatically using the canonical style. It’s not that this particular style is so wonderful in itself: it’s the standardisation which Rust and Go programmers appreciate.

If you like the functional style of programming, though, you’ll find a lot more facilities for it in Rust, because Rust has a lot more facilities than Go in general.

Ruby's keyword args work a little differently than similar implementations (selectors in Objective C, for instance). The value on the right-hand side of the colon is the default, not the local name.

I think RSpec should provide around(:context)/around(:all). Not because of any particular use case, but simply for API consistency. It's much simpler to tell users "there are 3 kinds of hooks (before, after and around) and each can be used with any of 3 scopes (example, context and suite)". Having some kinds of hooks work with only some kinds of scopes makes the API inconsistent and forces us to add special case code to emit warnings and also write extra documentation for this fact.

I've been thinking of looking into implementing this in rspec-core, primarily to make the API more consistent (e.g. so that you can combine any scope -- example/context/suite -- with any hook type before/after/around).

for parsing and converting a superset of Markdown

We overload the meaning of "GFM" to mean "GitLab Flavored Markdown", which is a superset of GitHub's version. However it can cause confusion as they are not the same thing.

"Context" manipulation is one of big topic and there are many related terminologies (academic, language/implementation specific, promotion terminologies). In fact, there is confusing. In few minutes I remember the following related words and it is good CS exam to describe each :p Thread (Ruby) Green thread (CS terminology) Native thread (CS terminology) Non-preemptive thread (CS terminology) Preemptive thread (CS terminology) Fiber (Ruby/using resume/yield) Fiber (Ruby/using transfer) Fiber (Win32API) Generator (Python/JavaScript) Generator (Ruby) Continuation (CS terminology/Ruby, Scheme, ...) Partial continuation (CS terminology/ functional lang.) Exception handling (many languages) Coroutine (CS terminology/ALGOL) Semi-coroutine (CS terminology) Process (Unix/Ruby) Process (Erlang/Elixir) setjmp/longjmp (C) makecontext/swapcontext (POSIX) Task (...)

What Makes Ruby on Rails Perfect for Marketplace Development?AlinaE-Commerce & SaaS StrategistMarketplaceRuby/RailsHomeBlogEntrepreneurshipWhat Makes Ruby on Rails Perfect for Marketplace Development?PublishedJul 13, 2020UpdatedJul 13, 202012 min readThe last several years have been marked with the rise of different marketplaces. Airbnb, AliExpress, Etsy, Booking.com are on everyone’s lips. That's not surprising that the idea of launching a second Amazon or eBay seems so appealing. To win the e-commerce race, entrepreneurs focus on providing excellent customer experience and build fast-loading and scalable websites. Besides, business owners take various security measures to protect their customers’ sensitive information. This way, they can gain clients’ trust and boost sales. When building a custom marketplace, what technology stack is best to achieve all these goals? Our answer is simple: Ruby on Rails. In this article, we will fill you in on the Ruby on Rails marketplace development. At Codica, we are passionate fans of this framework and have built numerous e-commerce platforms with its help. Based on our experience, we will discuss the key reasons to choose RoR for building a successful marketplace.

Another option is the use the functional library Ramda, while the syntax may be a bit different from the Ruby and Pure JS version, I find it to be more declarive: list = [null, "say", "kenglish", "co", null] R.reject(R.isNil, list) // return new array [ 'say', 'kenglish', 'co' ]

At the same time, details about programming language semantics are quite precise and when articles like this get things sort of wrong, it just leads to more confusion.

When people talk about internal DSLs I see two styles: internal minilanguages and language enhancements.

Same feature in TypeScript¶ It's worth mentioning that other languages have a shortcut for assignment var assignment directly from constructor parameters. So it seems especially painful that Ruby, despite being so beautifully elegant and succinct in other areas, still has no such shortcut for this. One of those other languages (CoffeeScript) is dead now, but TypeScript remains very much alive and allows you to write this (REPL): class Foo { constructor(public a:number, public b:number, private c:number) { } } instead of this boilerplate: class Foo { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } } (The public/private access modifiers actually disappear in the transpiled JavaScript code because it's only the TypeScript compiler that enforces those access modifiers, and it does so at compile time rather than at run time.) Further reading: https://www.typescriptlang.org/docs/handbook/2/classes.html#parameter-properties https://basarat.gitbook.io/typescript/future-javascript/classes#define-using-constructor https://kendaleiv.com/typescript-constructor-assignment-public-and-private-keywords/ I actually wouldn't mind being able to use public/private modifiers on instance var parameters in Ruby, too, but if we did, I would suggest making that be an additional optional shortcut (for defining accessor methods for those instance vars) that builds on top of the instance var assignment parameter syntax described here. (See more detailed proposal in #__.) Accessors are more of a secondary concern to me: we can already define accessors pretty succinctly with attr_accessor and friends. The bigger pain point that I'm much more interested in having a succinct shortcut for is instance var assignment in constructors. initialize(@a, @b, @c) syntax¶ jsc (Justin Collins) wrote in #note-12: jjyr (Jinyang Jiang) wrote: I am surprised this syntax has been repeatedly requested and rejected since 7 years ago. ... As someone who has been writing Ruby for over 10 years, this syntax is exactly that I would like. I grow really tired of writing def initialize(a, b, c) @a = a @b = b @c = c end This would be perfect: def initialize(@a, @b, @c) end I'm a little bit sad Matz is against this syntax, as it seems so natural to me. Me too!! I've been writing Ruby for over 15 years, and this syntax seems like the most obvious, simple, natural, clear, unsurprising, and Ruby-like. I believe it would be readily understood by any Rubyist without any explanation required. Even if you saw it for the first time, I can't think of any way you could miss or misinterpret its meaning: since @a is in the same position as a local variable a would normally be, it seems abundantly clear that instead of assigning to a local variable, we're just assigning to the variable @a instead and of course you can reference the @a variable in the constructor body, too, exactly the same as you could with a local variable a passed as an argument. A workaround pattern¶ In the meantime, I've taken to defining my constructor and list of public accessors (if any) like this: attr_reader \ :a, :b def new( a, b) @a, @b = a, b end ... which is still horrendously boilerplatey and ugly, and probably most of you will hate — but by lining up the duplicated symbols into a table of columns, I like that I can at least more easily see the ugly duplication and cross-check that I've spelled them all correctly and handled them all consistently. :shrug: Please??¶ Almost every time I write a new class in Ruby, I wish for this feature and wonder if we'll ever get it. Can we please?

Introduce behaviour that is likely to surprise users. Instead have due consideration for patterns adopted by other commonly-used languages.

in languages (like JavaScript and Java) where external objects do have direct access to instance vars

Having a member in a class and initializing it like below:class Foo { x: number; constructor(x:number) { this.x = x; }}is such a common pattern that TypeScript provides a shorthand where you can prefix the member with an access modifier and it is automatically declared on the class and copied from the constructor. So the previous example can be re-written as (notice public x:number):class Foo { constructor(public x:number) { }}

The answer is no, we use a pattern where we do this, and have a `static` method for manufacturing the constructor.e.g.static from({prop1, prop2}) => new this(public prop1, public prop2)

TypeScript includes a concise way to create and assign a class instance property from a constructor parameter.

Then, people from programming communities (mainly front-end) realized that CoffeeScript is out of date and is starting to lag behind the ever-evolving Javascript environment. As of today, January 2020, CoffeeScript is completely dead on the market (though the GitHub repository is still kind of alive).

Programmers should be encouraged to understand what is correct, why it is correct, and then propagate.

It seems inelegant to me to split this into two different modules, one to include, the other to extend.

Apparently when you create a subclass, that subclass's singleton class has # its superclass's singleton class as an ancestor.

Learn more about the Ruby's Object, Class & Module and the method receiver chain.

ProMotion is a RubyMotion gem that makes iOS development more like Ruby and less like Objective-C.

If this is okay, then it might even be nice if #dig took a block as well as a fallback value: [].dig(1) { 'default' } #=> "default"

Would it be desirable to specify the new object in a block? That would make it somewhat symmetrical to how Hash.new takes a block as a default value.

Title: "goal the use case is trying to satisfy"[23]:101 Main Success Scenario: numbered list of steps[23]:101 Step: "a simple statement of the interaction between the actor and a system"[23]:101 Extensions: separately numbered lists, one per Extension[23]:101 Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.

JavaScript needs to fly from its comfy nest, and learn to survive on its own, on equal terms with other languages and run-times. It’s time to grow up, kid.

If JavaScript were detached from the client and server platforms, the pressure of being a monoculture would be lifted — the next iteration of the JavaScript language or run-time would no longer have to please every developer in the world, but instead could focus on pleasing a much smaller audience of developers who love JavaScript and thrive with it, while enabling others to move to alternative languages or run-times.

multi-paradigm: functional, imperative

The forms of the final keyword vary:

But now, you can do the same thing in functional style!

Brings functional programming to Python land

I'm not a fan of listing exceptions functions can throw, especially here in Python, where it's easier to ask forgiveness than permission.

Another solution is using the Safe Navigation Operator &. introduced in Ruby 2.3 which is a bit better because this is a language feature rather than an opinionated runtime environment pollution

This is the most popular article “railway oriented programming” on one of the most popular websites of F #.

We think that, although Ruby is a great language for the backend, the view should be written in languages designed for that purpose, HTML and JavaScript.

Svelte is its own language, not plain HTML+CSS+JS

Thanks for posting this helpful, well written article. Learning programming, or any other thing one takes up, requires you to sit at one place have a plan of action for your study.

JavaScript is, of course, a dynamic language that allows you to add and remove objects and their members at any point in time. For many, this is precisely why they enjoy the language: there are very few constraints imposed by the language.

The problem is that not all tooling supports adding new dependencies from a transform. The first step is figuring out how this can be done idiomatically in the current ecosystem.

express one's model of Existence

create patterns & metaphor

it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.

some programming languages that provide lexical closures view encapsulation as a feature of the language orthogonal to object orientation.

Svelte, on the other hand, is a compiler. In a way, Svelte is more like a programming language than a library.

“I came to Rust from Haskell, and I feel that Haskell is a very elegant and safe language. The biggest differentiator for me is that there is a greater difference between high-performance code and idiomatic ‘clean’ code in Haskell than in Rust. Most Rust code looks like most other Rust code, even when it performs well. Haskell can become unfamiliar real quick if someone is operating under different libraries and goals from what you are typically doing. Small differences in syntax can result in huge differences in behavior, and Rust has more uniformity on that axis.”

Then when giving answers I'm even less certain. For example I see occasional how-to questions which (IMO) are ridiculously complex in bash, awk, sed, etc. but trivial in python, (<10 lines, no non-standard libraries). On such questions I wait and see if other answers are forthcoming. But if they get no answers, I'm not sure if I should give my 10 lines of python or not.

The above errors can be resolved by simply adding the ⚡attribute to the <html> tag like so: <html ⚡ lang="en">

<html ⚡>

⚡4email

A beginless range is experimentally introduced. It might not be as useful as an endless range, but would be good for DSL purposes.

the overloaded operators ¬, =, ≠, and abs are defined

Most of Algol's "special" characters (⊂, ≡, ␣, ×, ÷, ≤, ≥, ≠, ¬, ⊃, ≡, ∨, ∧, →, ↓, ↑, ⌊, ⌈, ⎩, ⎧, ⊥, ⏨, ¢, ○ and □) can be found on the IBM 2741 keyboard with the APL "golf-ball" print head inserted; these became available in the mid-1960s while ALGOL 68 was being drafted. These characters are also part of the Unicode standard and most of them are available in several popular fonts.

The programming language is augmented with natural language description details, where convenient, or with compact mathematical notation.

A NackClass is the same as NilClass except for any method it does not recognize, it return the instance of itself. nack.nack.nack.nack #=> nack Note I used to call this NullClass, but "nack" seems a little more fitting a term.

Reason is not a new language; it's a new syntax and toolchain powered by the battle-tested language, OCaml.

If you love Ruby, you'll enjoy CoffeeScript as it makes the JavaScript more like the Ruby.

Null Coalescing Operator

Perhaps part of the confusion - and you say this in a different way in your little memo - is that the C/C++ folks see OO as a liberation from a world that has nothing resembling a first-class functions, while Lisp folks see OO as a prison since it limits their use of functions/objects to the style of (9.). In that case, the only way OO can be defended is in the same manner as any other game or discipline -- by arguing that by giving something up (e.g. the freedom to throw eggs at your neighbor's house) you gain something that you want (assurance that your neighbor won't put you in jail).

Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names.

All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this.

Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types.

Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference.

Following Christopher Strachey,[2] parametric polymorphism may be contrasted with ad hoc polymorphism, in which a single polymorphic function can have a number of distinct and potentially heterogeneous implementations depending on the type of argument(s) to which it is applied. Thus, ad hoc polymorphism can generally only support a limited number of such distinct types, since a separate implementation has to be provided for each type.

In programming languages and type theory, parametric polymorphism is a way to make a language more expressive, while still maintaining full static type-safety. Using parametric polymorphism, a function or a data type can be written generically so that it can handle values identically without depending on their type.[1] Such functions and data types are called generic functions and generic datatypes respectively and form the basis of generic programming.

Dynamic dispatch