41–50 of 60 posts
My IDEa: HTML parsing & formatting within code comments: https://groups.google.com/forum/#!topic/ace-internals/pTcFXP...
Earlier quoted context omitted.
"I've put a lot of thought (about 6 years now) into a way to standardization communication between software systems and even parts of software. It's a hard problem to crack." HTTP? It's not perfect, but it seems to be what our industry has settled on as the universal way for pieces of software to talk to each other. If you are thinking in terms of the payload, JSON seems to be filling that role.
Http is a protocol we use to communicate between systems, that is true, but not the parts of software. For example, to print "Hello World" on the screen, we use a sub-routine like WriteLine. The standard we use to communicate between software sub-systems, in this case, is a function with parameters. So, WriteLine ("Hello World") pushes the text "Hello World" into the sub-routine WriteLine. Parameters are, for basical…
Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations. Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue. For the former howeve…
If you look at Xcode, it saw a significant improvement when it started using clang to build its indexes. That is purely a C, C++ and Objective-C front end to LLVM.
Xcode basically requires a significant portion of a compiler to provide a decent coding environment.
What you are suggesting is almost to create a compiler "protocol" that can handle all languages. I am not sure how much value you would get from such a protocol.
Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations. Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue. For the former howeve…
Earlier quoted context omitted.
Http is a protocol we use to communicate between systems, that is true, but not the parts of software. For example, to print "Hello World" on the screen, we use a sub-routine like WriteLine. The standard we use to communicate between software sub-systems, in this case, is a function with parameters. So, WriteLine ("Hello World") pushes the text "Hello World" into the sub-routine WriteLine. Parameters are, for basical…
Four months ago, Bret Victor published his "Future of Programming" Talk. The most inspiring part to me was his 'prediction' of discarding brittle api`s for systems that negotiate a communication protocol dynamically. (Toy example: modem filter negotiation) http://vimeo.com/71278954 Relevant explanation @ 13:30-16:30.
> api`s for systems that negotiate a communication protocol dynamically
I think the first step is to find a very easy way to describe communication between sub-routines/processes. Once people can hook things up and compose the interaction of software with foreign/unknown systems (all in real time while the software is running) then we can get systems to start doing it dynamically (run on sentence but ya).
Here's an IDE idea: create an industry standard plugin protocol. Most of the cool stuff an IDE does is code analysis and transformation e.g. refactoring, error analysis, and autofill. The other half is "makes coding pretty", "provides good shortcuts", and other UI considerations. Now for the latter - that is great, and everyone has different strengths and weaknesses. And that is just a UX issue. For the former howeve…
Haskell community already standardizes through the use of library APIs and command-line applications like ghcmod. Any editor/IDE can invoke these tools.
Earlier quoted context omitted.
Haskell community already standardizes through the use of library APIs and command-line applications like ghcmod. Any editor/IDE can invoke these tools.
How extensible is the Haskell IDE though? Is it's plugin model standardized?
Earlier quoted context omitted.
How extensible is the Haskell IDE though? Is it's plugin model standardized?
The haskell-suite exists as standard of sorts, but the IDE specific tooling generally just involves invoking them like command line applications and using stdout in your editor/IDE.
Earlier quoted context omitted.
The haskell-suite exists as standard of sorts, but the IDE specific tooling generally just involves invoking them like command line applications and using stdout in your editor/IDE.
So you are saying Haskell is still stuck at the command-line non-IDE world of tooling integrated via primitives pipes and such? Unix was great in the 80s.
That it's a command-line application also means it's "start up and throw away" which is easier to get working for most users than daemon based stuff. Typically once it's configured you don't touch it again. This allows people to build on each other's work which can lead to higher levels of abstraction and more human-oriented tooling.
The alternative is everybody having to write Haskell parsers and analysis tools over and over again before getting to the parts that actually make their editor/IDE different. The Clojure community has a similar ethos of tool sharing and reuse.
End users do not generally invoke these command line tools themselves, their editors/IDEs integrate them and offer the native trimmings the users would expect.
Why are you being so hostile? You're not making me want to share anything I know. I'm talking about the kinds of ecosystems that let people like you (that work on live-editing environments) focus on the parts that matter to you and you're behaving like a prick.