5 ms·

Author here - happy to answer any questions!

by pbiggar 7y ago

conorgriffin 7y ago
What is Dark’s biggest weakness (excluding the current lack of adoption)?
- pbiggar 7y ago
  Wow, what a start :) Probably the biggest one is that you have to leave your editor. If you've spent 20 years carefully configuring your vim or emacs setup, you're not going to be happy to give that up. Don't have a good solution to this right now either.
  - conorgriffin 7y ago
    Haha figured I’d get in early with a hard question. I signed up a long time ago out of curiosity, it’s been a while since then, looking forward to trying it out
  - Sophistifunk 7y ago
    Over all my years it's become clear to me that this attitude of refusing to give up a specific tool (and it's always something married to plain 1d text) is the biggest thing holding out industry back. I don't know if you can convince people to do it, but I'm glad somebody's trying.
    - imglorp 7y ago
      I'm glad someone's trying also. And the reason 1d text is hard to get rid of is not merely an editor (ie, an "app") but a galaxy of languages, tools, and operating systems built around 1d character streams. Everything from the serial driver to the style sheet can be manipulated with primatives for mapping, filtering, and composing character streams and operations on them. There ARE a bunch of benefits to structured code, for example Docker and npm/pip/etc have recently showed us a hint of what composition of standard components can bring. What might be missing from structured code is the rest of the primitives on ASTs. Once we have all that we can talk about backporting to emacs :)
      - icebraining 7y ago
        All code is structured, otherwise it couldn't be compiled/interpreted. The Go community, for example, doesn't need to store their code in some sort of custom binary format to apply changes: gofix works fine with plain text. Text is just a serialization format for those ASTs, no different than any binary format.
    - jrockway 7y ago
      I think people don't want to leave their editor because navigating and typing code is a large part of programming. If you try some new editor, it's always going to be pretty wonky. For example, I've been using the Arduino IDE recently. I am used to navigating lines with C-n and C-p. It's something I do thousands of times a day. In the Arduino IDE, those keys create a new sketch (something I want to do maybe once a week) and print the current sketch (something I imagine nobody wants to do ever). The UI is just not thought out at all. I don't think I'm being resistant to change. I think their IDE is just garbage. Some people have done new IDEs well, VSCode comes to mind. But replicating 40 years of features is not going to happen overnight, and some of those features are actually important. Figuring out which ones are the key. If you don't hit a developer's critical set of features, they aren't going to use your thing.
    - icebraining 7y ago
      What do you see we could improve if we only left text? I've read the promise many times, but never actually saw any convincing reasons. Text is just another format anyway.
  - oftenwrong 7y ago
    One editor setup cannot satisfy all of the diverse preferences of all "religious" editor users. You have to support significant customisation to "convert" us. Maybe the editor should be customisable via Dark itself? Alternatively, allow us to use our editor-of-choice and provide a language server to facilitate the creation of structured editing plugins for Dark. I would add that most applications, including most non-vi-or-emacs editors and web browsers, do not allow much customisation of how their input is mapped to actions in the software. For someone like me, a person that is a vi die-hard because of its ergonomics, this is absolutely critical. Post-input customisation, no matter how advanced, cannot satisfy this need.
    - pbiggar 7y ago
      > Maybe the editor should be customisable via Dark itself? That's the plan!
djm_ 7y ago
Other languages have large ecosystems of packages that allow users to do common tasks quickly. I can imagine not having something similar would be a sticking point to adoption; how does Dark picture the Dark ecosystem working and competing with other already well-entrenched ecosystems? Thanks!
- pbiggar 7y ago
  There's a couple of ways of handling this. First is that of course we need to create a package manager and ecosystem, and that will take time (we can accelerate it by making a great experience, but haven't gotten there yet). Dark can talk to other HTTP things, so many of the functions that are done by libraries can be done over HTTP. So you can call other services, even if we don't have an SDK for that yet. And from there it should be easy to package it up so there is an SDK. Finally, it's a question of what you're doing. There's many tasks where the disadvantage of not having an ecosystem is outweighed by Dark's other advantages. And as we grow the ecosystem, the disadvantages go away, unlike the status quo tooling.
manoji 7y ago
I am not able to signup for beta with an organization email address. is this intended?
- pbiggar 7y ago
  No it's not! Sorry about that. Email me direct (see my profile) and I'll try to fix it.
the_duke 7y ago
Dark sounds like an interesting concept. I seriously hope though that you will open source the compiler. I can't see Dark going anywhere without a guarantee that you can use it without using the provided infrastructure and that your code will work fine even if Dark goes away or you decide to host it yourself. I certainly won't touch Dark with a 10 foot pole otherwise. And would advise anyone against it strongly.
ToJans 7y ago
I see quite some similarities with low-code systems, 4GLs, smalltalk etc, so AFAIK the market is there... Please take into account that your target audience probably is not on HN. If I would be you, I would target web agencies, that can use the dark platform as a competitive advantage, if your system allows you to build stuff faster... IMO it does not make sense to learn all these new paradigms for a small project, you really need scale for this kind of investment from your customers... Right now it feels like you are building a solution that does not know which specific problem it is solving...
alexashka 7y ago
Hi Paul, How did the decision to create a whole new language take place? Was using existing languages a serious consideration and if so, what were the trade-offs that made you go in this direction? I'm familiar with the basics of back-ends. Let's say you had a language that compiles each back-end point into a binary executable (each api point is a separate program). All you'd need is versioning via directories, symlinks to the active most up to date version and a router that looks up the executables in a dir and routes to them. Making changes would involve changing the code, pressing "deploy" which pushes to github and gets the backend to pull, re-compile the binaries and update symlinks. Given this setup - what does your approach do that's more than what I've just described? I'm assuming there's some fundamental problem my naive approach does not handle that made you go in the direction that you've just described.
- pbiggar 7y ago
  We did of course consider it. I don't think it's possible to use existing languages to do this. Presumably, we'd have to use Javascript as our basis cause everyone knows Javascript. But then we'd have people wanting "Dark for python" and "Dark for Ruby" and "Dark for rust", etc, which making a new language neatly sidesteps. So if we built it for javascript, we'd need to decide how to support all of JS's features. How do we support eval? How do we support Typescript and Flow and ReasonML? Then we'd be stuck with all the JS mistakes: promises and futures and callbacks and object model and null/undefined/0/"" comparison tables. This list keeps going: it would have to use a parser. It would need to support npm, etc, etc. I expect once people see Dark that they'll try to build similar features for existing languages, and I hope they succeed! There's some companies that are doing similar things, and I think the scale of their vision is much lower, partially because they are limited by language choice.
  - alexashka 7y ago
    Hm, your answer is not what I was expecting :) Some follow up questions if you are up for it: What are the fundamental features of Dark that are not possible to add to an existing language? What are the fundamental features of an existing language that are not possible to restrict via enforcing a subset, that are fundamental to Dark? Is Dark a very domain specific language? Perhaps these questions will better be answered by a demo that is coming in September.
leonaves 7y ago
Is it possible to write code in an offline environment (e.g. on a plane)?
- pbiggar 7y ago
  Yes, we'll have support for that, including handling sync conflicts when you get back online. It's not gonna be a great experience since Dark is really really designed for working on production, but it should work ok.

Author here - happy to answer any questions!

conorgriffin 7y ago

What is Dark’s biggest weakness (excluding the current lack of adoption)?

pbiggar 7y ago
Wow, what a start :) Probably the biggest one is that you have to leave your editor. If you've spent 20 years carefully configuring your vim or emacs setup, you're not going to be happy to give that up. Don't have a good solution to this right now either.
- conorgriffin 7y ago
  Haha figured I’d get in early with a hard question. I signed up a long time ago out of curiosity, it’s been a while since then, looking forward to trying it out
- Sophistifunk 7y ago
  Over all my years it's become clear to me that this attitude of refusing to give up a specific tool (and it's always something married to plain 1d text) is the biggest thing holding out industry back. I don't know if you can convince people to do it, but I'm glad somebody's trying.
  - imglorp 7y ago
    I'm glad someone's trying also. And the reason 1d text is hard to get rid of is not merely an editor (ie, an "app") but a galaxy of languages, tools, and operating systems built around 1d character streams. Everything from the serial driver to the style sheet can be manipulated with primatives for mapping, filtering, and composing character streams and operations on them. There ARE a bunch of benefits to structured code, for example Docker and npm/pip/etc have recently showed us a hint of what composition of standard components can bring. What might be missing from structured code is the rest of the primitives on ASTs. Once we have all that we can talk about backporting to emacs :)
    - icebraining 7y ago
      All code is structured, otherwise it couldn't be compiled/interpreted. The Go community, for example, doesn't need to store their code in some sort of custom binary format to apply changes: gofix works fine with plain text. Text is just a serialization format for those ASTs, no different than any binary format.
  - jrockway 7y ago
    I think people don't want to leave their editor because navigating and typing code is a large part of programming. If you try some new editor, it's always going to be pretty wonky. For example, I've been using the Arduino IDE recently. I am used to navigating lines with C-n and C-p. It's something I do thousands of times a day. In the Arduino IDE, those keys create a new sketch (something I want to do maybe once a week) and print the current sketch (something I imagine nobody wants to do ever). The UI is just not thought out at all. I don't think I'm being resistant to change. I think their IDE is just garbage. Some people have done new IDEs well, VSCode comes to mind. But replicating 40 years of features is not going to happen overnight, and some of those features are actually important. Figuring out which ones are the key. If you don't hit a developer's critical set of features, they aren't going to use your thing.
  - icebraining 7y ago
    What do you see we could improve if we only left text? I've read the promise many times, but never actually saw any convincing reasons. Text is just another format anyway.
- oftenwrong 7y ago
  One editor setup cannot satisfy all of the diverse preferences of all "religious" editor users. You have to support significant customisation to "convert" us. Maybe the editor should be customisable via Dark itself? Alternatively, allow us to use our editor-of-choice and provide a language server to facilitate the creation of structured editing plugins for Dark. I would add that most applications, including most non-vi-or-emacs editors and web browsers, do not allow much customisation of how their input is mapped to actions in the software. For someone like me, a person that is a vi die-hard because of its ergonomics, this is absolutely critical. Post-input customisation, no matter how advanced, cannot satisfy this need.
  - pbiggar 7y ago
    > Maybe the editor should be customisable via Dark itself? That's the plan!

djm_ 7y ago

Other languages have large ecosystems of packages that allow users to do common tasks quickly. I can imagine not having something similar would be a sticking point to adoption; how does Dark picture the Dark ecosystem working and competing with other already well-entrenched ecosystems? Thanks!

pbiggar 7y ago
There's a couple of ways of handling this. First is that of course we need to create a package manager and ecosystem, and that will take time (we can accelerate it by making a great experience, but haven't gotten there yet). Dark can talk to other HTTP things, so many of the functions that are done by libraries can be done over HTTP. So you can call other services, even if we don't have an SDK for that yet. And from there it should be easy to package it up so there is an SDK. Finally, it's a question of what you're doing. There's many tasks where the disadvantage of not having an ecosystem is outweighed by Dark's other advantages. And as we grow the ecosystem, the disadvantages go away, unlike the status quo tooling.

manoji 7y ago

I am not able to signup for beta with an organization email address. is this intended?

pbiggar 7y ago
No it's not! Sorry about that. Email me direct (see my profile) and I'll try to fix it.

the_duke 7y ago

Dark sounds like an interesting concept. I seriously hope though that you will open source the compiler. I can't see Dark going anywhere without a guarantee that you can use it without using the provided infrastructure and that your code will work fine even if Dark goes away or you decide to host it yourself. I certainly won't touch Dark with a 10 foot pole otherwise. And would advise anyone against it strongly.

ToJans 7y ago

I see quite some similarities with low-code systems, 4GLs, smalltalk etc, so AFAIK the market is there... Please take into account that your target audience probably is not on HN. If I would be you, I would target web agencies, that can use the dark platform as a competitive advantage, if your system allows you to build stuff faster... IMO it does not make sense to learn all these new paradigms for a small project, you really need scale for this kind of investment from your customers... Right now it feels like you are building a solution that does not know which specific problem it is solving...

alexashka 7y ago

Hi Paul, How did the decision to create a whole new language take place? Was using existing languages a serious consideration and if so, what were the trade-offs that made you go in this direction? I'm familiar with the basics of back-ends. Let's say you had a language that compiles each back-end point into a binary executable (each api point is a separate program). All you'd need is versioning via directories, symlinks to the active most up to date version and a router that looks up the executables in a dir and routes to them. Making changes would involve changing the code, pressing "deploy" which pushes to github and gets the backend to pull, re-compile the binaries and update symlinks. Given this setup - what does your approach do that's more than what I've just described? I'm assuming there's some fundamental problem my naive approach does not handle that made you go in the direction that you've just described.

pbiggar 7y ago
We did of course consider it. I don't think it's possible to use existing languages to do this. Presumably, we'd have to use Javascript as our basis cause everyone knows Javascript. But then we'd have people wanting "Dark for python" and "Dark for Ruby" and "Dark for rust", etc, which making a new language neatly sidesteps. So if we built it for javascript, we'd need to decide how to support all of JS's features. How do we support eval? How do we support Typescript and Flow and ReasonML? Then we'd be stuck with all the JS mistakes: promises and futures and callbacks and object model and null/undefined/0/"" comparison tables. This list keeps going: it would have to use a parser. It would need to support npm, etc, etc. I expect once people see Dark that they'll try to build similar features for existing languages, and I hope they succeed! There's some companies that are doing similar things, and I think the scale of their vision is much lower, partially because they are limited by language choice.
- alexashka 7y ago
  Hm, your answer is not what I was expecting :) Some follow up questions if you are up for it: What are the fundamental features of Dark that are not possible to add to an existing language? What are the fundamental features of an existing language that are not possible to restrict via enforcing a subset, that are fundamental to Dark? Is Dark a very domain specific language? Perhaps these questions will better be answered by a demo that is coming in September.

leonaves 7y ago

Is it possible to write code in an offline environment (e.g. on a plane)?

pbiggar 7y ago
Yes, we'll have support for that, including handling sync conflicts when you get back online. It's not gonna be a great experience since Dark is really really designed for working on production, but it should work ok.