Red Lang goes blockchain(red-lang.org)
red-lang.org
Red Lang goes blockchain
http://www.red-lang.org/2017/12/leaping-into-future-red-goes-blockchain.html
100 comments
s/Naned/Nenad
I recently got interested in J too by the way, how do you use this language and Lisps in your work?
I recently got interested in J too by the way, how do you use this language and Lisps in your work?
The APLs and especially, for me, j and k, are really interesting languagues. For one, I agree with Whitney, the creator of k, that you should not have to scroll to read your software. I think making sure at least every function points fits on a phone screen is a large boon for readability and maintainability. It is not the fact that it fits there, it is more so that if it does, you can work on that implementation mentally focused: without jumping pages or even files. I know a lot of people find j,k and even Forth unreadable, but that is really just practice. When I got used to it, I found, for instance, c# a lot more annoying to read. It is somewhat (this is a bit over the top, but you get the idea) the difference between reading Godel his original whitepaper (in German ofcourse) and Godel, Escher Bach explaining that whitepaper. Both are good reads, but the original paper, when you have the background context, is easier to read and debug that that enormous volume.
I hope to find more time to explore these avenues. For now, k and forth mixtures are my favorite to mess around with; I created a little language to do live coding on my phone for Xamarin and the forth/k mix I use is actually the first thing that is not annoying to work with on a phone screen. Because most happens in your brain and what you type is a few hieroglyphs, the development is interactive, you can walk around doing it. I hope to clean it up enough to release it (I am old, I do not like this releasing of half baked stuff usually, unless it is game related): it saves me a lot hell doing edit/compile/wait/test cycles.
For playing around, check out oK : it is a k implementation in JS, it is slow but works everywhere and has some cool features for making graphics and little games.
I hope to find more time to explore these avenues. For now, k and forth mixtures are my favorite to mess around with; I created a little language to do live coding on my phone for Xamarin and the forth/k mix I use is actually the first thing that is not annoying to work with on a phone screen. Because most happens in your brain and what you type is a few hieroglyphs, the development is interactive, you can walk around doing it. I hope to clean it up enough to release it (I am old, I do not like this releasing of half baked stuff usually, unless it is game related): it saves me a lot hell doing edit/compile/wait/test cycles.
For playing around, check out oK : it is a k implementation in JS, it is slow but works everywhere and has some cool features for making graphics and little games.
I am familiar with k and oK. Is your unreleased language closer to forth or k? Sounds interesting. I checked out Sporth by a fellow named Paul Batchelor. Pretty cool stuff. He's going in different directions nowadays I think, but stil livecoding tools.
Sounds interesting! Will check it out. My language is closer to Forth; I borrowed ways of making code terser from k mostly, but I like the way of not having variables (when possible) without making too much off a mess. And the way k does that feels inelegant to me somehow.
Edit: Live coding really helps though; the whole Bret Victor thing and Light table etc but also many artists and game devs before that, know that you want sculpt your ideas first before you stabilize them. Aka you want spreadsheet programming but when you have more or less what you want, you want to 'upgrade' that code so it's not 'spreadsheet programming' anymore. We have the first (live coding environments, usually for art, Forth etc), we have the middle (REPLs, Lisp) and we have the last part (strongly typed languages and even formal verified programming), but we don't have something that flows from begin to end without having to rewrite everything every stage. I think Lisp / Clojure fans believe they do have this, but I don't find it convincing (although I love coding in Lispy's). I feel Forth has the 'beginning' down much more than Lisp, but moving from a 'working' mess to something stable and then to something rocksolid is not so easy. I keep experimenting.
Edit: Live coding really helps though; the whole Bret Victor thing and Light table etc but also many artists and game devs before that, know that you want sculpt your ideas first before you stabilize them. Aka you want spreadsheet programming but when you have more or less what you want, you want to 'upgrade' that code so it's not 'spreadsheet programming' anymore. We have the first (live coding environments, usually for art, Forth etc), we have the middle (REPLs, Lisp) and we have the last part (strongly typed languages and even formal verified programming), but we don't have something that flows from begin to end without having to rewrite everything every stage. I think Lisp / Clojure fans believe they do have this, but I don't find it convincing (although I love coding in Lispy's). I feel Forth has the 'beginning' down much more than Lisp, but moving from a 'working' mess to something stable and then to something rocksolid is not so easy. I keep experimenting.
I can't go back and edit the spelling error, thanks anyway.
I use J daily on my desktop as a calculator, and for more involved calculations. I am a senior project manager/technical designer/business developer at an engineering firm in the their Entertainment department. We do rock concerts, Broadway, film, live events, theme parks, stage machinery, art installation engineering and more. J is like my quicker-than-Excel-tryout-space. I have developed more mathematically-heavy applications in it, but when the need is for something beyond J's strengths of array handling and beautiful succinctness, I reach for Lisp for developing more of what people call apps, but they are for my sole use. Particularly SBCL. I also use Emacs Lisp a lot, since I am in Emacs all day for org-mode, writing, coding and LaTex. I am addicted to Emacs. It is the Lisp Machine for me until another is developed, or I can afford a relic.
I picked up Shen [1] a few years back to keep me from straying to far into Haskell/Idris, and I am working through The Book of Shen 3rd Edition. I had looked into Wasp Lisp years ago for fun, but I am now looking more into it since Chris Double ported Shen (and with it Klambda) over to the Wasp Lisp [2]. It made me leave any studies I started of Erlang or LFE, since my focus is on networking and distributed computing as a hobby. I always stay up to date with Racket, and use it for procedural geometry generation using Rosetta [3] instead of Rhino and Grasshopper. I actually used it to generate procedural truss for a sphere and then exported the centerlines to run analysis on the structure in RISA 3D [4].
I like to fiddle with Extempore for livecoding, but I am a mere dilettante [5]
I use J daily on my desktop as a calculator, and for more involved calculations. I am a senior project manager/technical designer/business developer at an engineering firm in the their Entertainment department. We do rock concerts, Broadway, film, live events, theme parks, stage machinery, art installation engineering and more. J is like my quicker-than-Excel-tryout-space. I have developed more mathematically-heavy applications in it, but when the need is for something beyond J's strengths of array handling and beautiful succinctness, I reach for Lisp for developing more of what people call apps, but they are for my sole use. Particularly SBCL. I also use Emacs Lisp a lot, since I am in Emacs all day for org-mode, writing, coding and LaTex. I am addicted to Emacs. It is the Lisp Machine for me until another is developed, or I can afford a relic.
I picked up Shen [1] a few years back to keep me from straying to far into Haskell/Idris, and I am working through The Book of Shen 3rd Edition. I had looked into Wasp Lisp years ago for fun, but I am now looking more into it since Chris Double ported Shen (and with it Klambda) over to the Wasp Lisp [2]. It made me leave any studies I started of Erlang or LFE, since my focus is on networking and distributed computing as a hobby. I always stay up to date with Racket, and use it for procedural geometry generation using Rosetta [3] instead of Rhino and Grasshopper. I actually used it to generate procedural truss for a sphere and then exported the centerlines to run analysis on the structure in RISA 3D [4].
I like to fiddle with Extempore for livecoding, but I am a mere dilettante [5]
[1] http://shenlanguage.org/
[2] https://github.com/doublec/shen-wasp
[3] http://web.ist.utl.pt/antonio.menezes.leitao/Rosetta/tutorials/introduction.html
[4] https://risa.com/p_risa3d.html
[5] https://github.com/digego/extemporeHave you dabbled with Julia [1] before? It sounds like it might be right up your alley. It's not a lisp, but it's very "lispy" in a lot of ways, and it's focused on scientific/numeric computing with an active community focused on the same. The creators also mentioned J as an influence I believe, though I haven't used J myself, so I can't comment on that.
[1] https://julialang.org
[1] https://julialang.org
Yes I have. J and Wasp Lisp are tiny ecosystems, and I like that a lot about them. Julia is trying to be a Matlab replacement and a whole lot more. I'm going to wait until it matures. I'm teetering on Zig and Rust for my C replacement and as a hook into J’s libraries, or a Wasp VM written in Rust.
Thanks for reply!
edit
I know we're all experiencing blockchain fatigue, but for once, I actually know what the tokens will be used for (beyond the usual snake-oil that other ICOs sell). For reference:
Some of the target usages for the token holders, will include:
- voting rights: influence the Red roadmap, vote for features and issue tickets.
- tipping: useful chat posts, code contributions, learning materials providers, etc.
- intra-community cryptoeconomics (or rather tokenomics): selling/buying services from other community members (coding tasks, consulting, learning help, bug fixing, decentralized gaming, etc.)
- paid Dapps, or in-app purchases.
In addition to that, the foundation will hold a significant amount of RCT, which will be used for rewarding:
- code contributions
- Red-related online learning or presenting materials (blog, documentations, etc.)
- promotional actions (presenting Red at a conference)
- any other actions that will help spread Red and make the community grow up.
I'm not sure I personally agree with turning the org into a "dapp", unless language-design remains with the core designers of the language and doesn't become influenced by decentralized decisions. edit: It looks like "voting rights" may actually impact this
There is always an issue with OSS projects struggling for funding. Regardless of how flawed the idea may be, at least they are trying to find a model to sustain themselves. It certainly trumps the model of depending on big-tech-company-X giving you handouts for your SSL library.
I know we're all experiencing blockchain fatigue, but for once, I actually know what the tokens will be used for (beyond the usual snake-oil that other ICOs sell). For reference:
Some of the target usages for the token holders, will include:
- voting rights: influence the Red roadmap, vote for features and issue tickets.
- tipping: useful chat posts, code contributions, learning materials providers, etc.
- intra-community cryptoeconomics (or rather tokenomics): selling/buying services from other community members (coding tasks, consulting, learning help, bug fixing, decentralized gaming, etc.)
- paid Dapps, or in-app purchases.
In addition to that, the foundation will hold a significant amount of RCT, which will be used for rewarding:
- code contributions
- Red-related online learning or presenting materials (blog, documentations, etc.)
- promotional actions (presenting Red at a conference)
- any other actions that will help spread Red and make the community grow up.
I'm not sure I personally agree with turning the org into a "dapp", unless language-design remains with the core designers of the language and doesn't become influenced by decentralized decisions. edit: It looks like "voting rights" may actually impact this
There is always an issue with OSS projects struggling for funding. Regardless of how flawed the idea may be, at least they are trying to find a model to sustain themselves. It certainly trumps the model of depending on big-tech-company-X giving you handouts for your SSL library.
People who buy into the ICO can influence the roadmap?
Isn't that design by committee? (Generally considered a bad idea.)
Isn't that design by committee? (Generally considered a bad idea.)
I imagine it will be useful only for prioritization.
Correct, though we can't predict the future. If somebody throws huge amounts of money at Red they could influence the language. Then it's up to the team and community to decide if it's worth including, or risking a fork. It's open source after all.
I dont think that this is a real possibility. Like I cant imagine why they would. And like what's the potential damage here? A new keyword? Slightly better http support than there would be otherwise? What's the danger?
Very little danger, especially to the core language. One scenario is that someone wants to add support for all kinds of features by adding large, external dependencies, thinking it will make Red more marketable. But the language isn't the thing to sell. Really hard to do that anymore, sad but true. The thing to sell is tools that help people get their job done and make their lives easier. Red is just the thing we want to use to build those tools.
Literally everything except “voting rights” is better served by a more popular existing cryptocurrency, and program language design doesn’t need a fancy voting system.
ICOs increase the emotional connection to a project by catering to the "in-group" tribal mentality no matter the original intent (i.e. greed). It can be debated how (or whether) this is fallacious, but the empirical evidence thus far indicates this model generally raising funds more quickly and in larger quantities than mere donations.
Rent-seeking and design by committee. Imagine they charged dollars instead of their own coin (it would be cheaper to do so).
> but for once, I actually know what the tokens will be used for
Do you seriously believe that people will give you the benefit of the doubt when you are repeating the exact same hype and promise that almost all blockchain/ico projects have done in the past?
Do you seriously believe that people will give you the benefit of the doubt when you are repeating the exact same hype and promise that almost all blockchain/ico projects have done in the past?
Oh boy. It would suck ass to see those guys busted by SEC for offering unregistered securities. The voting rights will definitely make it a security from SEC's standpoint, so the only question is whether they will be considered too small of a fish to bother.
The irony with the ICO market is that it's safe for total scams with untraceable founders and it's safe for big players like FileCoin that voluntarily comply with the securities laws. But if you're a well-meaning techie with no legal team, you may be easily breaking dozens of security-related regulations without even realizing it.
The irony with the ICO market is that it's safe for total scams with untraceable founders and it's safe for big players like FileCoin that voluntarily comply with the securities laws. But if you're a well-meaning techie with no legal team, you may be easily breaking dozens of security-related regulations without even realizing it.
The SEC has absolutely no say in this whatsoever, as the Red Foundation is being set up in France.
Not sure what to think of this. Smells like FOMO. I looked at their roadmap and they're planning to support so many different architectures. Adding EVM support seems like adding more complexity to the project just because blockchain.
I think something like this is needed for programming on blockchain, but I'd prefer to see a dedicated project instead.
I think something like this is needed for programming on blockchain, but I'd prefer to see a dedicated project instead.
also, documentation seems to have be an after thought. I want to like Red, but the documentation has been so scattered, unorganized and limited, I felt more slowed than I needed to be.
Will still keep an eye on Red though, hoping it will improve on that level
Will still keep an eye on Red though, hoping it will improve on that level
It's not an afterthought, but it takes a lot of time and work. The project priorities are driven by the people paying for the work, and it hasn't been a priority for them. We hope the new projects will allow us to improve the situation. In the meantime, telling us what docs are most lacking, or most needed, helps.
If you follow Red, you know that avoiding complexity is a primary goal. Each new back end may add some complexity, but it doesn't change the underlying model of how Red is implemented. And I think it will be kind of what you say you want. It is a dedicated project, with the current goal of raising money so a team can focus on that. Think of it as your dedicated project using Red to build the blockchain programming tool. It wouldn't have to be all Red, that's just the best approach in this case.
>I looked at their roadmap and they're planning to support so many different architectures.
Yes, I noticed and was concerned about that too - that they may be taking on too much work. Otherwise I like their goals (apart from this latest news).
Yes, I noticed and was concerned about that too - that they may be taking on too much work. Otherwise I like their goals (apart from this latest news).
“but after studying many other ICO, I am convinced now that this is not just a short-lived fad, but a real new model to fund projects, and especially open-source projects related to blockchains.”
There’s been quite a few of us suggesting people jump into blockchain just to get funding for more important stuff (e.g. language-level tooling or libraries) they’ll produce as part of the coin offering they sell to investors. Plus, with the focus on correctness, it’s easier than ever to get the private sector to invest in high-assurance tooling. Problem is they keep trying to clean-slate everything when there's piles of work to build on with better benefits in the long term. And this work is hard even when doing simple things if you want end result to be widely usable. So, you better have a good justification for trying to redo decades worth of hard work on your own with some VC funding.
Anyone wanting a shortcut should build your language on top of capabilities of the SPARK Ada language [1] with this book [2]. Your smart contracts get all the benefits it currently offers plus whatever extra you build plus whatever they build with the influx of money for Pro edition. Recent projects already add some pointer [3] and floating-point [4] safety to what they already mostly automate with that tooling. This is also a mature tool whose development and commercial use goes back decades [5].
[1] https://en.wikipedia.org/wiki/SPARK_(programming_language)
[2] https://www.amazon.com/Building-High-Integrity-Applications-...
[3] https://arxiv.org/abs/1710.07047
[4] http://lists.forge.open-do.org/pipermail/spark2014-discuss/2...
[5] http://www.spark-2014.org/uploads/itp_2014_r610.pdf
There’s been quite a few of us suggesting people jump into blockchain just to get funding for more important stuff (e.g. language-level tooling or libraries) they’ll produce as part of the coin offering they sell to investors. Plus, with the focus on correctness, it’s easier than ever to get the private sector to invest in high-assurance tooling. Problem is they keep trying to clean-slate everything when there's piles of work to build on with better benefits in the long term. And this work is hard even when doing simple things if you want end result to be widely usable. So, you better have a good justification for trying to redo decades worth of hard work on your own with some VC funding.
Anyone wanting a shortcut should build your language on top of capabilities of the SPARK Ada language [1] with this book [2]. Your smart contracts get all the benefits it currently offers plus whatever extra you build plus whatever they build with the influx of money for Pro edition. Recent projects already add some pointer [3] and floating-point [4] safety to what they already mostly automate with that tooling. This is also a mature tool whose development and commercial use goes back decades [5].
[1] https://en.wikipedia.org/wiki/SPARK_(programming_language)
[2] https://www.amazon.com/Building-High-Integrity-Applications-...
[3] https://arxiv.org/abs/1710.07047
[4] http://lists.forge.open-do.org/pipermail/spark2014-discuss/2...
[5] http://www.spark-2014.org/uploads/itp_2014_r610.pdf
Thanks for the info @nickpsecurity!
Not sure why people are so skeptical. I'm hoping for ICO to become a successful model for open source projects. Maybe more projects will be able to sustain themselves with ICOs, Patreon, donations.
I was pretty sure it was going to be a joke, but like the Long Blockchain Company announcement[1], it's pretty apparent that its real. Good god.
[1]: http://money.cnn.com/2017/12/21/investing/long-island-iced-t...
[1]: http://money.cnn.com/2017/12/21/investing/long-island-iced-t...
Exciting stuff. Just a heads up that NEO is being marketed as a decentralized platform but its roadmap describes a platform run by Trusted Third Parties, which have to be approved by NEO after proving their identity and proving they have a legal entity backing them.
The NEO team also promotes itself as compliant with regulations (probably to stay on the good side of the authorities in China where it is based). If they want to go down this route, that's their prerogative, but it's downright misleading to describe it as decentralized or even as in the same space as cryptocurrency. It's more like a traditional Fintech company, with greater separation of concerns between users and trusted third parties (e.g. updates to the database are cryptographically validated, with each user controlling their own private keys to authorize updates to their respective account), to provide more transparency and security than closed database models.
I would add Ripple, Stellar and EOS to this class of pseudo-cryptocurrency platforms, that while arguably offering interesting innovations on the centralized server-client architecture, are exploiting the hype around decentralization to raise funds and users for platforms that are not decentralized.
Its centralized consensus model means NEO can afford to place very high resource loads on its nodes (or really, servers), and use traditional programming languages that are not optimized for the decentralized world. This ability to use Java, C# and Python to write programs for it is actually one of its features that is marketed on its website.
The NEO team also promotes itself as compliant with regulations (probably to stay on the good side of the authorities in China where it is based). If they want to go down this route, that's their prerogative, but it's downright misleading to describe it as decentralized or even as in the same space as cryptocurrency. It's more like a traditional Fintech company, with greater separation of concerns between users and trusted third parties (e.g. updates to the database are cryptographically validated, with each user controlling their own private keys to authorize updates to their respective account), to provide more transparency and security than closed database models.
I would add Ripple, Stellar and EOS to this class of pseudo-cryptocurrency platforms, that while arguably offering interesting innovations on the centralized server-client architecture, are exploiting the hype around decentralization to raise funds and users for platforms that are not decentralized.
Its centralized consensus model means NEO can afford to place very high resource loads on its nodes (or really, servers), and use traditional programming languages that are not optimized for the decentralized world. This ability to use Java, C# and Python to write programs for it is actually one of its features that is marketed on its website.
There is nothing misleading about it at all. A delegated system is decentralized, whether it is decentralized enough for you is your decision, but it is misleading to claim otherwise.
Disclosure: NEO fan
Disclosure: NEO fan
A set of trusted third parties that are pre-approved by a central authority, and are operating in a platform designed to comply with rules created by a central authority (the government), is not decentralized, in any context, let alone in the cryptocurrency context, where the original Bitcoin whitepaper describes a radical consensus algorithm designed specifically to make trusted third parties unnecessary.
You could call it federated, but not decentralized.
You could call it federated, but not decentralized.
This radical consensus mechanism has led to multiple hostile parties go into a pseudo economic war with each other. These parties are fairly centralized, miners, developers, and business interests, with the users largely standing on the sidelines of all of this.
A decentralized system takes power from one party and moves it to multiple parties. That is the definition of decentralization. A decentralized system is not one that completely does away with trust. That would be a trustless system.
A decentralized system takes power from one party and moves it to multiple parties. That is the definition of decentralization. A decentralized system is not one that completely does away with trust. That would be a trustless system.
>>This radical consensus mechanism has led to multiple hostile parties go into a pseudo economic war with each other.
I'm not arguing about the merits of its consensus algorithm or of decentralization. I'm providing context for how the term 'cryptocurrency' originated, and how 'decentralization' was used in this context.
Having a central authority determine who can be a consensus server, and being explicitly designed to put known and trusted third parties in charge to comply with the rules of a central governing authority, is not a decentralized system, especially in the context of cryptocurrency, where the term was used in relation to the absence of trusted third parties.
The economic wars you speak of could put to question whether Bitcoin succeeded in being decentralized, but it doesn't change the fact that NEO and other permissioned blockchains run by pre-approved and known trusted third parties, are definitely not decentralized.
>>A decentralized system takes power from one party and moves it to multiple parties.
But the ultimate power still resides in the hands of one party in NEO, because there is one party acting as a gatekeeper, deciding what can happen on its ledger, and who can run a server.
To call this decentralization, with whaboutisms about problems in the Bitcoin space, that are not even comparable, to justify the characterisation, is disingenuous.
I'm not arguing about the merits of its consensus algorithm or of decentralization. I'm providing context for how the term 'cryptocurrency' originated, and how 'decentralization' was used in this context.
Having a central authority determine who can be a consensus server, and being explicitly designed to put known and trusted third parties in charge to comply with the rules of a central governing authority, is not a decentralized system, especially in the context of cryptocurrency, where the term was used in relation to the absence of trusted third parties.
The economic wars you speak of could put to question whether Bitcoin succeeded in being decentralized, but it doesn't change the fact that NEO and other permissioned blockchains run by pre-approved and known trusted third parties, are definitely not decentralized.
>>A decentralized system takes power from one party and moves it to multiple parties.
But the ultimate power still resides in the hands of one party in NEO, because there is one party acting as a gatekeeper, deciding what can happen on its ledger, and who can run a server.
To call this decentralization, with whaboutisms about problems in the Bitcoin space, that are not even comparable, to justify the characterisation, is disingenuous.
I don't think that we will be able to convince each other. If you think that everyone needing to run a validating node in a blockchain ecosystem to be decentralized, then NEO certainly won't fit your criteria. I don't subscribe to this definition of decentralization
You're right that we won't convince each other and that carrying this on isn't a good use of either of our time.
I'll add however that "everyone running a validating node" is not my definition of decentralization. Needing to 1. identify oneself to the NEO Council, 2. be a legal entity and 3. get approval from the NEO Council, to run a fully validating node, is not decentralization according to any meaningful definition of the term.
If federations of trusted third parties are decentralized, then corporations with multiple shareholders are decentralized. Even the Federal Reserve, with its regional banks voted in by the member banks of each respective district, is decentralized, by this loose definition.
I'll add however that "everyone running a validating node" is not my definition of decentralization. Needing to 1. identify oneself to the NEO Council, 2. be a legal entity and 3. get approval from the NEO Council, to run a fully validating node, is not decentralization according to any meaningful definition of the term.
If federations of trusted third parties are decentralized, then corporations with multiple shareholders are decentralized. Even the Federal Reserve, with its regional banks voted in by the member banks of each respective district, is decentralized, by this loose definition.
I was actually looking at Red in consideration for my next year's personal projects.
I'd consider it further if I felt it was more complete. Perhaps this is a cursory evaluation, but it feels like the emphasis is to use what's built in as much as possible. Given a lack of json (yes, there is an implementation out there, but not built in), and still pending linux GUI support, it still feels too unfinished for me to invest my time into.
I'd consider it further if I felt it was more complete. Perhaps this is a cursory evaluation, but it feels like the emphasis is to use what's built in as much as possible. Given a lack of json (yes, there is an implementation out there, but not built in), and still pending linux GUI support, it still feels too unfinished for me to invest my time into.
The lack of Linux GUI support is a dealbreaker for me.
Neither of those features have been a priority, but both will eventually be built in. We'll wait for you. :^)
Curious - How is Red sustained, who currently supports it? Or what does the roadmap look like for this to be a five-year sustainable project?
Edit: They seem to address this down in the blog post, with the creation of a RCT token. What is the incentive for a potential backer to buy this token?
Edit: They seem to address this down in the blog post, with the creation of a RCT token. What is the incentive for a potential backer to buy this token?
@ZenoArrow is correct. Nenad Rakocevic supported himself, with modest donations and other work, until he could raise the initial investment money. He and another full time developer have been working on it for a few years, using those resources. This is the next phase, with one goal being to grow the core team, but also encourage community involvement by being able to reward people.
One incentive for backers is if they want a say in how things are prioritized.
One incentive for backers is if they want a say in how things are prioritized.
> What is the incentive for a potential backer to buy this token?
I would imagine to support the developers.
They also claim it might be used as gas on the blockchain in the future so if you want to run a dapp you will need it.
I would imagine to support the developers.
They also claim it might be used as gas on the blockchain in the future so if you want to run a dapp you will need it.
> "How is Red sustained, who currently supports it?"
IIRC there's a Chinese company that pays the lead developer to work on it.
IIRC there's a Chinese company that pays the lead developer to work on it.
I am excited. Wish they wrote more details on how to participate in ICOs as some - like me - never have.
Step 1: don't live in the US.
(I'm a bit jealous.)
(I'm a bit jealous.)
Just use an VPN if you want to participate
[deleted]
[deleted]
> We have produced a whitepaper earlier this year in October (co-authored by Tamas Herman and myself), to describe with more details and context what we are building. We will release it publicly in a few days.
Why not release them simultaneously?
Why not release them simultaneously?
> Nenad Rakocevic @dockimbel 00:35
> @OneArb I need to update the whitepaper with latest data, so it should be available maybe tomorrow, or in a couple of days.
— https://gitter.im/red/blockchain?at=5a4128da0163b02810796948
> @OneArb I need to update the whitepaper with latest data, so it should be available maybe tomorrow, or in a couple of days.
— https://gitter.im/red/blockchain?at=5a4128da0163b02810796948
Thank you.
What has been the most successful use of smart contracts so far?
That hasn't ended in theft (so far)? CryptoKitties, probably. https://www.cryptokitties.co/
I was hoping the Red project would announce something interesting at the end of the year; but not something as interesting as this.
We live in interesting times.
Do they have a plan for staying on the windy side of the SEC, or should US residents stay away?
God! Enough! At this point any announcement with "blockchain" should turn any informed person off of the whole project. Checking out Red was on my roadmap and now it's firmly not.
You certainly should check Red anyway. It is still the same language as yesterday, before any "blockchain" announcement. No buzzword can change the great design.
It's not though. This announcement shows the direction that those in charge of Red plan to take it.
If you think that's a stupid direction, then that should influence your decision to invest any time in learning or building upon that language.
If you think that's a stupid direction, then that should influence your decision to invest any time in learning or building upon that language.
Can you clarify how you see that direction?
I wish I knew how to fight this idea that a project is its code, and not its community and values and expected future. GNOME 2 is certainly not the same GNOME 2 as it was 10 years ago, despite the code not having gone everywhere. Something like MATE might be, but its difference from GNOME 2 lies precisely in its existence as a community with values separate from the GNOME community and values.
Just because you hate blockchain tech doesn't mean the rest of the world should pass up free money.
Also, "any informed person" is the No True Scotsman fallacy. I'm informed and I don't feel negatively just because it's blockchain.
Also, "any informed person" is the No True Scotsman fallacy. I'm informed and I don't feel negatively just because it's blockchain.
What stupid comment is this ? Red is an amazing tool for creating DSL it's a logical that it goes this path.
Please don't name-call in comments. Apart from breaking the site rules (https://news.ycombinator.com/newsguidelines.html), it discredits your point. That's particularly bad when your point is good.
Don't be so narrow-minded.
Buzzwords and cryptocurrencies speculations aside, Red is really worth checking, at least if you're a language enthusiast and is interested in Forth and Lisp family.
And here blockchain is nothing more than an innovative (yet rather controversial, I agree, since I'm skeptical too) model to sustain programming language community and gain a solid ground for core developing team.
Buzzwords and cryptocurrencies speculations aside, Red is really worth checking, at least if you're a language enthusiast and is interested in Forth and Lisp family.
And here blockchain is nothing more than an innovative (yet rather controversial, I agree, since I'm skeptical too) model to sustain programming language community and gain a solid ground for core developing team.
Red has potential, but certainly has had slow progress; shifting focus to blockchain may increase total resources but even if it does it mostly likely means slowing down progress outside of the new focal domain.
So, I can see it legitimately killing interest at the margins for those not specifically not interested in blockchain-focussed programming.
So, I can see it legitimately killing interest at the margins for those not specifically not interested in blockchain-focussed programming.
This is a valid concern.
As I understood from my discussion with Nenad (lead developer), making such move was a hard decision to make. On the one hand, it MAY actually pay-off in a long term for whole language ecosystem overall, but on the other hand, for that we need to pay the price of slower development and releases delays.
To answer another point (if I understand it correctly) - you don't really need to be interested in blockchains and stuff (personally I don't) to participate in community and programming with Red, there's lots of other things to play with (metaprogramming, language-oriented programming, reactive programming, data-driven programming, parsing, DSL and eDSLs, baking cross-platform GUIs, system programming with Red/System).
As I understood from my discussion with Nenad (lead developer), making such move was a hard decision to make. On the one hand, it MAY actually pay-off in a long term for whole language ecosystem overall, but on the other hand, for that we need to pay the price of slower development and releases delays.
To answer another point (if I understand it correctly) - you don't really need to be interested in blockchains and stuff (personally I don't) to participate in community and programming with Red, there's lots of other things to play with (metaprogramming, language-oriented programming, reactive programming, data-driven programming, parsing, DSL and eDSLs, baking cross-platform GUIs, system programming with Red/System).
> it mostly likely means slowing down progress outside of the new focal domain.
IIRC, at the end of last year they promised 1.0 by the end of this year.
Then they missed a 0.6.x release by four months. Now they don't even talk about a 1.0 and even minor releases no longer have a due date [1]
So yes, all these additional endeavours will definitely slow an already slow progress to a halt.
I also wonder if they finally fully implemented integers and floats...
[1] https://github.com/red/red/milestones
IIRC, at the end of last year they promised 1.0 by the end of this year.
Then they missed a 0.6.x release by four months. Now they don't even talk about a 1.0 and even minor releases no longer have a due date [1]
So yes, all these additional endeavours will definitely slow an already slow progress to a halt.
I also wonder if they finally fully implemented integers and floats...
[1] https://github.com/red/red/milestones
> "IIRC, at the end of last year they promised 1.0 by the end of this year."
To be honest, I don't think that was ever a realistic goal, even when it was set. The only benefit of setting such a goal ahead of when a clear release date can be determined is in keeping up momentum during the awkward middle phase of language maturity, when key functionality is clearly missing but you want to maintain interest. This isn't just a Red thing, it's fairly common.
If I had to guess, even by the end of next year, it's much more likely we'll be looking at a 0.7.x release (or, best case, 0.8.x) rather than 1.0. The good news is that the language is likely to be generally useful around 0.7.x (assuming the roadmap is stuck to), as that's the point when the network I/O features are being implemented.
To be honest, I don't think that was ever a realistic goal, even when it was set. The only benefit of setting such a goal ahead of when a clear release date can be determined is in keeping up momentum during the awkward middle phase of language maturity, when key functionality is clearly missing but you want to maintain interest. This isn't just a Red thing, it's fairly common.
If I had to guess, even by the end of next year, it's much more likely we'll be looking at a 0.7.x release (or, best case, 0.8.x) rather than 1.0. The good news is that the language is likely to be generally useful around 0.7.x (assuming the roadmap is stuck to), as that's the point when the network I/O features are being implemented.
I’m with you about blockchain announcements, but this looks like it’s actually appropriate.
From the linked page: “Such dialect will compile to the Ethereum VM (EVM) bytecode directly as first target, and more backends will be added later to support other chains, like NEO. ”
That seems significant to me.
From the linked page: “Such dialect will compile to the Ethereum VM (EVM) bytecode directly as first target, and more backends will be added later to support other chains, like NEO. ”
That seems significant to me.
Sounds like an opportunity for a startup.
JSON input in one format, let the SaaS translate it to ETH, NEO, etc.
Thoughts/
JSON input in one format, let the SaaS translate it to ETH, NEO, etc.
Thoughts/
I wish they'd stopped there. An ICO on top of it makes no sense to me as anything but a demo-net for the EVM backend.
Agreed. Blockchains have yet to power anything of practical value. They're arguably technically interesting, and may be useful in the long term, but the hype is pathetic and embarrassing.
I don't get why this comment is being downvoted? There's nothing that suggests that blockchain is seeing mass adoption other than the people pushing it.
So far it has proved to be a fantastic vehicle for transferring wealth from unsuspecting investors in the hands of the few who promises the world but will not actually deliver because you know, regulation is a thing of the past.
So far it has proved to be a fantastic vehicle for transferring wealth from unsuspecting investors in the hands of the few who promises the world but will not actually deliver because you know, regulation is a thing of the past.
The benefits section of Red is a pretty amazing list most languages can't say:
http://www.red-lang.org/p/about.html
Its Red/System DSL [1] is also something that could be easily used or improved by folks like you that build OS's on calculators and such. More talent can only help. ;) I've been eyeballing it for a concept of high-level systems programming that extracts to multiple targets to leverage their static/dynamic analysis, testing, and compilers. Keep feeding any improvements detected by each into original code until result is pretty solid. Additionally, a language with features close to C that's easy to macro can by itself be advantageous as a C replacement. Double true if the initial interpreter for that language is easy to implement in C or assembly.
So, try it out. Just ignore the blockchain BS if you don't like that. Worst case in event you really like Red, but not what's on the submission, is that you fork or partly clone the prior work to leverage its benefits minus the bullshit. :)
Note: This is true for any great language or other tooling that's malleable. Easier to escape lock-in to specific paths the maintainers take. Not necessarily easy but easier.
[1] http://static.red-lang.org/red-system-specs.html
http://www.red-lang.org/p/about.html
Its Red/System DSL [1] is also something that could be easily used or improved by folks like you that build OS's on calculators and such. More talent can only help. ;) I've been eyeballing it for a concept of high-level systems programming that extracts to multiple targets to leverage their static/dynamic analysis, testing, and compilers. Keep feeding any improvements detected by each into original code until result is pretty solid. Additionally, a language with features close to C that's easy to macro can by itself be advantageous as a C replacement. Double true if the initial interpreter for that language is easy to implement in C or assembly.
So, try it out. Just ignore the blockchain BS if you don't like that. Worst case in event you really like Red, but not what's on the submission, is that you fork or partly clone the prior work to leverage its benefits minus the bullshit. :)
Note: This is true for any great language or other tooling that's malleable. Easier to escape lock-in to specific paths the maintainers take. Not necessarily easy but easier.
[1] http://static.red-lang.org/red-system-specs.html
> "Checking out Red was on my roadmap and now it's firmly not."
What I'd suggest is that this DSL for blockchain contracts is not really part of the core Red language. It's worth being aware that Red does not have a module system yet, but there are plans for one before version 1.0. I'd fully expect work like this contract DSL to be spun off into a module once the module functionality is in place.
What I'd suggest is that this DSL for blockchain contracts is not really part of the core Red language. It's worth being aware that Red does not have a module system yet, but there are plans for one before version 1.0. I'd fully expect work like this contract DSL to be spun off into a module once the module functionality is in place.
Yeah I actually couldn't believe what I was seeing when the other day I was actually thinking this about Red Lang, 'this actually could be onto something'...
It completely erodes trust and confidence when a project just bolts on a blockchain...it makes me question if they are in this for the long haul or just want to cash out.
It completely erodes trust and confidence when a project just bolts on a blockchain...it makes me question if they are in this for the long haul or just want to cash out.
bart42_0(1)
I just bet myself 5:95 odds (lose means donate directly to the org - they just missed out on 12.5k) that there would be only rent-seeking or “voting” in the “token use cases”. These guys don’t know what they don’t know.
Also, HA HA HA. I used to feel bad for the victims but now I think they deserve it.
Also, HA HA HA. I used to feel bad for the victims but now I think they deserve it.
Please don't post snarky dismissals to HN, even if something else is wrong or bad. That's no reason to make this place worse.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Fantastic news !!!
Priorities. He realized that buzzwords are more important than multithreading.
Its like a traditional ICO, but the code is already written. Interesting approach
Not really:
> We are at the design stage, the first alpha (prototype) is planned for end of Q1 2018.
> We are at the design stage, the first alpha (prototype) is planned for end of Q1 2018.
I am sticking with my Lisps (SBCL, Racket, Emacs Lisp, Shen, and Wasp Lisp) for now, and my beloved J [2], but I love the size of the whole Red/Red System environment. I think it is going to take off.
I know Naned, the man behind Red, was CEO of Fullstack Technologies, and it was based in Beijing after an initial $500k VC funding round from Chinese VCs [1].
Curiously, I predict a bunch of conspiracy theory people to relate Red = Communism, Blockchain/ICO/Coins = Socialized currency, and a decentralized internet running DAPPs to dilute the USA's currernt juice in the internet all with a connection back to China, but I am ecstatic about a distributed internet that cannot be censored like it is in China, or in less obvious ways in the US. I missed the Bitcoin buy-in when it was selling at $200-something, but I always knew in my readings that the blockchain is its secret sauce. Aside from the energy expenditure, I like the concept. How can it, or can it become energy efficient, but still stay difficult to mine to work out both ways? Seems like it will not be possible. You cannot make it easy for everyone, and hard enough to have value...