rm82 · HackerTrans

Wow, plunker seems really nice. You really do make a strong case with the package catalogue.

Some questions though:

Would you consider adding automatic server-side proccessing in the future based on file-extension? For example, compiling .less to .css on the fly?

I think, one of the more interesting directions of a web-based IDE is that they can stop pretending to be a file-editor on a file-system.

I also notice streams. Is this true collaborative editing?

rm82

12년 전discuss

I'm actually hoping for a transition to a situation where your favorite web framework, will come with its own web-based IDE.

Esspecially at the web-development side of things, IDE integration isn't optimal. It's not so much that the languages themselves need better integration; it's the frameworks, and the abstractions and tooling they bring.

When it gets this easy to create a web-based IDE, why even bother trying to develop a one-size-fits-all super IDE? Why not just have a simple IDE that targets one particular framework and its (likely opiniated) workflow? I mean, right now, most of that stuff, targets the command line as their primary UI.

rm82

12년 전discuss

Well, most of those use the ACE editor component, rather than the CodeMirror editor component.

I don't know why and obviously, this isn't true for everybody, but i'm always at war with CodeMirror. It auto-outdents and reformats things exactly how i do not want them. Whenever i'm forced to use CodeMirror, i'm undo-ing more than i'm typing and swearing about once every 5 seconds.

So, if you are one of those people, like me, that is always getting furious at jsFiddle, try an ACE based alternative.

Interestingly, once you realize that these code-editor components are quite simple to implement on a web-site, you also understand why there are 100+ jsFiddles clones. Most, if not all web-devs should be able to create one in half a day. They may think it's harder before they begin, but they will be pleasantly suprised.

This is likely also, why we're seeing a new "Online IDE" every week these days. GitHub's new Atom.io editor is the first one in a long time, to not use CodeMirror or ACE at its core.

rm82

13년 전discuss

>Also, I wish people would stop conflating "religious" functional programming with pragmatically expressing algorithms as compositions of functions.

Yes, me too. And that type of functional programming is very popular and very succesfull. Every programmer uses it often, when they touch SQL, jQuery, LINQ, etc.

>I don't think you and I really disagree much on the big picture.

I love functional programming.

But i consider languages like Haskell and their derivates to do a lot of harm to the reputation of functional programming. Lazy evaluation and the whole pretending math == computation. It's borderline harmfull to the development of a programmer to even be exposed to it. The last thing you want a programmer to believe, is that there is some intrinsic order of execution that is magically correct and optimal, and can easily be derived. There isn't. The correct order of execution is not even objective (in a GUI one would trade throughput for lower latency, for example), so the notion we can just skip that whole part, and have the 'compiler take care of it' seems damaging to me. Languages that allow you to specifiy these things manually are considered ugly mutations of some kind of pure math. Sinners. That we need return to one true god, which is "pure" math, mascerading as a term rewriter and bible full of fine print, and a zero tolerance on maintaining global state. Yuck.

rm82

13년 전discuss

>But when people wanted to think clearly, they invented math,

No, they didn't. They invented a syntax two milleniums ago, optimized for use-cases of those ages, using alphabets of those times. Thinking in greek symbols is not helping anyone think clearly. It's just more confusion, because now suddenly, i can't type or phrase a relevant question out loud, until i get a greek keyboard and learn the proper pronounciations of the greek alphabet.

The notion we should just stick to a notation and conventions optimized for a different era, a different culture, a different alphabet and a different writing tool (paper), is ridiculous. Do NASA scientists calculate speed using knots? Or power using horse power? They do not.

Math is to computer science, what classical music is to pop music. A historical relic that stopped having economic and cultural value beyond being a mere status symbol.

>of which FP is nearly the computational manifestation.

No, it's not. One could argue the same thing for logic programming. Computation is not the manifestation of math. It's a strategy to answer a mathametical question. The original strategy was to just 'try things and explore' and when you found (guessed?) the answer, you would prove it to be sure.

Functional programming, in the religious Haskell sense, is just a term rewriter. That's not the manifestation of computation. It's just one way to specify a strategy. In the case of Haskell, which is a term rewriter with a bible full of fine print and exceptions, a very sado-machistic one.

>But computers are primarily about information, and we think about information in terms of relationships

No, that would be Prolog. A different default strategy. Less fine print, but not the cure-all either.

>That's exactly what FP is about: expressing computation in terms of relationships.

Nope. A relationship doesn't have a computational direction. In math, all these statements express the same relationship:

    double( x ) / x = x
    double( x ) = x * x
    x * x = double( x )

In Haskell, only one of them happens to be legal. Because you are not writing a mathematical equation. You are specifying a computation. The fact that isn't even obvious, makes matters worse.

> But computers are primarily about information, and we think about information in terms of relationships

Yes, and the biggest challenge, the pain everyone tries to lessen, is managing the coordination and standardisation of changes (mutations) to that information. Wrapping every computation with the same type of state-monad actually helps a lot with this, and has been the most popular strategy to deal with this problem in the last 20 years.

rm82

13년 전discuss

>I would argue that the "anything goes" dynamic procedural languages ( like Ruby, Python ) are far more anti-human,

Is it anti-human to be able to interact with the code, and explore what it actually does? A run-time type error is one that has real example data.

The assumption we can write perfect code immediately and easily, or that a type analysis can just guide us through, is not the case. And it's breaks down even worse, when 99% of your code is interacting with systems outside of the scope of the typing system. (database servers, client-side browsers, network connections, file-systems). Dynamically typed language are good fits, when the code is mostly glue-code between multiple systems outside of the scope of any type analysis.

But let's not equate functional programming with static typing.

>in languages that provide a strong theoretic framework for reasoning about code.

You act like many of us are ever writing complicated algorithms. We're not. We're writing simple algorithms that deal with complex structures of information. And in the few cases where the algorithms get so complicated you want your invariants to be formally proven, anything less than a full blown theory prover, will be insuffient anyway.

comments