Haxe Studio version 0.5 released

[HaxeStudio pahArif]

Hi all,

We've released Haxe Studio version 0.5. 

download it here

Changelog v0.5

============

• Complete rewrite in Javascript
  
• uses promises
  
• anyword completion always available
  
• Haxe completion uses CTRL/META + Space on '.' and '('
  
• Haxe completion have description
  
• Auto switch to next tab if the active tab are closed.
  
• increase speed by converting watch object to promises
  
• fix inconsistence in multi os by change menu to HTML
  
• new theme
  
• new 'new project' mechanism.
  
• new 'new project' template, openfl & haxeflixel
  
• add console
  
• Include About page
  
• Include Update page

[HaxeStudio pahArif]

You can read how to use Haxe Studio v0.5 here.

[Jonas Malaco Filho]

I'm curious: why the change to manually written JS?

[HaxeStudio pahArif]

Because im more fluent in Javascript compared to Haxe. Plus, no extern & untyped & easier to seperate code into plugins

On 24 Jan 2015 14:35, "Jonas Malaco Filho" <jo...@jonasmalaco.com> wrote:

I'm curious: why the change to manually written JS?

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Marcelo de Moraes Serpa]

I know this is off topic, but one *could* argue Haxe adds friction when it comes to compiling to js If you are really well-versed in Javascript already. While I like the prospect of a statically-typed js app, I’m yet to try it with an app I write, so I can’t really judge. But I’ve heard from other people came with the opinion that in most cases, it’s better to just embrace javascript with a bit more discipline than to switch to Haxe. The main problem here, It think, is the additional workload of creating/maintaining externs and mapping features from Haxe to js, which get on the way.

Food for thought.

You received this message because you are subscribed to the Google Groups "Haxe" group.

[Marcelo de Moraes Serpa]

Although I can think of cases when Haxe can actually lead to better productivity by providing some additional syntactic sugar and abstraction through macros, like the @async metadata provided by haxe-js-kit*[0]

*[0] https://github.com/clemos/haxe-js-kit

</off-topic>

[Simon Krajewski]

Am 24.01.2015 um 23:53 schrieb Marcelo de Moraes Serpa:

Although I can think of cases when Haxe can actually lead to better productivity by providing some additional syntactic sugar and abstraction through macros, like the @async metadata provided by haxe-js-kit*[0]

Oh well, at least you give us _something_!

Simon

[HaxeStudio pahArif]

Lol.

Using Haxe in this is overkill. its like using diamond to cut a pillow. It will do a great job with high precision, but yeah.. overkill.

BTW,
Haxe studio adopt plugin mechanism, so anyone may write a Haxe-js based plugin. Slaps some API and you can use PHP & Python :)

Plugins only introduce functions. Integration were done seperately by js files using event listeners. event listeners then invoke function inside the plugin and do accordingly.

maybe a explanation diagram would be nice..

--

[Philippe Elsass]

The friction when working in JS are the external APIs. Typescript/Flow have the same problem when you want to use typing, but working untyped is entirely without friction.

Haxe is too strict/convoluted for common mortals even when it comes to writing untyped code. I know the reasons (and the progress like require meta) but still wish there was a better way.

PS: using Haxe for HaxeStudio is far from overkill imho; it sadly shows that it's too easy to give up.

You received this message because you are subscribed to the Google Groups "Haxe" group.

[Simon Krajewski]

Am 25.01.2015 um 02:38 schrieb HaxeStudio pahArif:
>
> Lol.
>
> Using Haxe in this is overkill. its like using diamond to cut a
> pillow. It will do a great job with high precision, but yeah.. overkill.
>

I really have to wonder why you are developing a Haxe IDE if you think
the language is overkill for targeting Javascript.

Simon

[Philippe Elsass]

Yes, creating a complete editor is a considerable job - you could better use your JS skills making a good Brackets or Atom.io Haxe integration.

Really there are good web-based editors and that's where Haxe should be integrated instead of starting from scratch.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--- You received this message because you are subscribed to the Google Groups "Haxe" group.

[Juraj Kirchheim]

On Sun, Jan 25, 2015 at 10:16 AM, Philippe Elsass <philipp...@gmail.com> wrote:

The friction when working in JS are the external APIs. Typescript/Flow have the same problem when you want to use typing, but working untyped is entirely without friction.

Haxe is too strict/convoluted for common mortals even when it comes to writing untyped code. I know the reasons (and the progress like require meta) but still wish there was a better way.

PS: using Haxe for HaxeStudio is far from overkill imho; it sadly shows that it's too easy to give up.

If it makes you sad to see people giving up on haxe/js, you should really stop perpetuating claims about it being hard to use.

Best,

Juraj

[Justin L Mills]

Such a shame, I am a bit lost on the history, you join a Haxe community funded project, of a code editor specifically written in Haxe, then decide you don't have the skill to code it in haxe and fork/port it to another language?

That seems a good way to piss off a language community - since you still keep Haxe in it's name, really that is not doing Haxe any favours, can you perhaps address that soon!

While fullofCaffine has been very generous in his comments I have a suspicion he is very unlikely to find your project code base interesting now that it's moved to js, so there is this large focused community, that were interested in your project, that are now feeling kind of appathetic and certainly unlikely to pitch in on the code base, I mean I am pretty sure a commercial editor like intellij is far better, much more worthwhile for some of us to pitch in on improving the plugin for that.

I think you missed compleately the point of a Haxe editor and lost access to a rich skill base, I have written many lines of Haxe js for pleasure but really I do not see any point in coding js directly and there are many, many far more skilled than me around here, I regularly see Haxe deveolpers reach outside thier normal language and apply thier skill sideways but they don't have the time for js mess unless they do that as a day job and then why would they do that on thier weekends, they have probably been trying to convince the boss to let them switch to haxe and you just made it that much harder. Really js is one of the worst languages to directly code in from what I can see - Do you have a native php backend involved perhaps you should add one! 

Really I feel you don't understand the point of Haxe, and I don't understand the point of your project it seems to have lost its way?

Please can you move the code base to as3 AIR, then that way if it turns out useful I can more easily port it back to Haxe instead of that compleately untyped mess that is native js!

I am yet to be convinced by the arguments in favour, and very much doubt I would try using this project, it seems far more worthwhile using something like intelij or FDT that probably still need work, and I myself would be interested in any project connected with improving opensource textmate2 for Haxe use, again I make the point... the whole point of writting an editor in haxe from scratch was to take advantage of haxe if you don't think you can do that then why did you get involved?

I wish you luck in your javascript editor but have to award you a

-1

for starting a rather disappointing thread, that probably leaves quite a few of us feeling sad, maybe the only good thing that comes out of it are ideas on how to improve haxe js further.

You received this message because you are subscribed to the Google Groups "Haxe" group.

[Philippe Elsass]

Please pardon me for not being very constructive as I post this "constatation" regularly without suggesting concrete solutions.

Coding using Haxe JS is my day job and my joy, and I'm doing my best to convince more people to use it, but although the language features appeal easily to JS coders looking for a better JS, there are a number of friction points which discourage them to going further.

--

[HaxeStudio pahArif]

wow.. 

I'm sorry to all of you & the community..

I never think writing the IDE this way will affect things soo much.

I really, really think that you want a cross-platform, Haxe Compatible, IDE for Linux, Windows and OSX.

On that part, I really think I've done good job.

But, I miss out the utmost crucial point , "written in pure Haxe"

As i have taken a portion of the community fund, i am responsible with the community.

I think i'm starting to see what you all saw.

I will convert Haxe Studio's native JS into Haxe JS.

It will take a while, but the port will be 100% Haxe JS code.

The architecture, GUI will remain as such (HTML + JS library)

I'm sorry for letting down all of you.

it's not my intention to do this.

again, sorry.

ps : 
Please keep track of this branch https://github.com/misterpah/Haxe-Studio/tree/haxejs to make sure i make this IDE as the community intended.

[Philippe Elsass]

I really think you should still consider making a great Brackets or Atom.io Haxe plugin: writing a complete editor/IDE is no fun and good Haxe integration enough work as is. You probably already have a lot pieces ready for that.

[HaxeStudio pahArif]

Regarding the Brackets or Atom.io Haxe Plugin, Atom.io is extremely similar to what I've done in Haxe Studio.

i see what i can do..

ps :

if i'm able to write an Atom haxe plugin, does it redeem myself from doing a bad job on Haxe Studio?

Still, I'll be porting Haxe Studio to HaxeJS as the community have asked me to deliver it.

pps :

I'm a muslim. These things means a lot to me. 

[Juraj Kirchheim]

On Sat, Jan 24, 2015 at 11:48 PM, Marcelo de Moraes Serpa <fullofc...@gmail.com> wrote:

I know this is off topic, but one *could* argue Haxe adds friction when it comes to compiling to js If you are really well-versed in Javascript already.

If you are equally well-versed in Haxe, then no. That's just usually not what people compare.

While I like the prospect of a statically-typed js app, I’m yet to try it with an app I write, so I can’t really judge.

Well, do try it and let us know what issues you run into ;)

 

But I’ve heard from other people came with the opinion that in most cases, it’s better to just embrace javascript with a bit more discipline than to switch to Haxe.

I have to ask: Did the people who hold that opinion ever really embrace Haxe?

The main problem here, It think, is the additional workload of creating/maintaining externs and mapping features from Haxe to js, which get on the way.

Not really, no. The problem lies in the approach. During the last WWX I had a couple of conversations about haxe/js and this subject. The issue here is that most people try to write externs for whole libraries at a time. In 95% of the cases you will be needing 5% of its API. If you have the time to create and maintain full externs for a library, then great. If not, then focus on your job and save the world another day ;)

Best,

Juraj

[Philippe Elsass]

IMHO a good Atom.io integration (even written in JS) would be a lot more valuable than yet another half-baked webkit-based editor whatever the language.

[HaxeStudio pahArif]

GREAT !
I will follow your request and make a good Atom.io Haxe integration.

[Juraj Kirchheim]

On Sun, Jan 25, 2015 at 4:59 PM, HaxeStudio pahArif <haxes...@gmail.com> wrote:

if i'm able to write an Atom haxe plugin, does it redeem myself from doing a bad job on Haxe Studio?

I think nobody actually says you have done a bad job. And you certainly do not need to redeem yourself in any way.

You have just taken one decision that most of us feel is really quite unfortunate. There are two good options:

1. Write a Haxe plugin for a well supported editor such as atom/brackets etc. (or maybe consider a non js based option).

2. Write a Haxe editor in Haxe.

The first option leverages the tremendous momentum of the JS community in general and the editor's contributors in particular. There's really very little use in efforts such as writing your own file tree view or what not.

The second option is very interesting for the Haxe community. It gives us an editor we can hack on in our language. It gives us something to be part of our show case. To me, those are two very good reasons.

So unlike Philippe I am not convinced the first option is clearly better. But with HIDE also tackling the second one and your main expertise being JS, the first option is probably more suitable for you.

Best,

Juraj

[Philippe Elsass]

That's what I meant :)

--

[Justin L Mills]

+1 on option 2, I think it's more interesting long term, and will get a lot more haxe traction in terms of code contibutions if it's done well.

[Philippe Elsass]

Option 1 can be quickly fruitful and rewarding: editors exist, are solid, pleasant, and popular. Concentrate on great Haxe completion, workflow and templates: that's already a lot for one dev to do well.

About option 2: can we discuss about bringing some focus/contributions around HIDE?

[Johann]

On Sunday, January 25, 2015 at 10:16:48 PM UTC+1, Philippe Elsass wrote:

Option 1 can be quickly fruitful and rewarding: editors exist, are solid, pleasant, and popular. Concentrate on great Haxe completion, workflow and templates: that's already a lot for one dev to do well.

There seem to be some misconceptions regarding the "Why" of a Haxe based editor/IDE. 

First of all, and most generally, and in stark contrast to JS, Haxe is a language well-suited for big projects, and a non-toy editor/IDE is a big project. 

Then, a good IDE provides certain non-trivial things, like refactoring tools. Refactoring requires the IDE to have an idea of the structure of a program, which for Haxe is basically the (typed) AST (plus some information that gets lost during parsing one really wants to maintain so the results look good/preserve style etc.). Haxe comes with ADTs, which, by far, are the best abstraction to represent ASTs known to mankind, and, guess what, it of course comes with both its own untyped and typed ASTs, ready to use, in the std lib. 

Whatever people could possibly come up with in JS to represent them: 

1. please, I don't want to see it.

2. how long will it take you to write it, to write the tests, to debug it

3. how long and how contrived will the code *using* such an abomination be instead of a simple and elegant pattern match on the haxe side of things? 

Then, UI programming - a bit of a horrible thing, but fortunately declarative programming makes it a lot nicer, and/or perhaps you're a fan of reactive programming, or whatever - Haxe is perfectly suited and comes with all and *solid* tools to perform the compile-time transformations required for such little helpers with big impact, something that's half-assedly bolted on, less powerful, way less general, and reimplemented every time, in the JS versions of these frameworks.

Having loosely followed HIDE and Haxe Studio, it soon became clear that it's unreasonable to expect their developers to be aware of why Haxe is so much superior to most languages for this Job, which is alright, of course, there's always a lot to learn for all of us.

But what needs to be said is that once someone/some team aware of what Haxe actually is and can do, decides to write an UI-framework, and based on that, an IDE, such a thing will be light-years from what you can possibly dream to achieve in JS, in terms of code-size, maintainability, extendability and everything else that makes the difference in software engineering. 

Whatever non-trivial task comes up, there simply is no comparison between Haxe and JS, and the insinuation that rewriting something in Haxe that already exists in JS would be a pointless act of vanity (that's how you put it in a different thread, Philippe), is, well, I don't want to sound inflammatory here, but please, please, reconsider your attributions about JS software here, you're writing in the context of Haxe, the language, and in that context, what might be outstanding in JS, is mediocre at the very best.

regards, Johann

[Philippe Elsass]

@Johann I don't want to sound inflammatory here, but you seem to have a personal issue with JS which clouds a bit your judgement ;)

But I do think HIDE's codebase is disappointing: the Haxe code is a bit messy and the UI hacked a bit cheaply using jQuery and lots of untyped code. That could be solved progressively with discipline, contributions and supervision - disdain won't help.

Did the foundation try to mediate the conflict to get the 2 devs back together? The reason invoked for the fork is rather mundane.

If they really don't want to work together I'd rather see some effort in adding Haxe support to some existing web IDE, that's all. Such plugin could still be written in Haxe.

Cheers

--

To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

--

Philippe

[Tarwin Stroh-Spijer]

Yeah, kind of upsets that there is two groups trying to make an IDE. Fine, if things are working already and you are at a stable point, and you want to then head in different directions, go ahead. But try and work together for no other reason than the community really NEEDS a good IDE. (Windows FlashDevelop is amazing BTW)

Tarwin Stroh-Spijer
_______________________

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)

Original at Touch My Pixel (touchmypixel.com)
_______________________

[Johann]

On Monday, January 26, 2015 at 6:16:41 PM UTC+1, Philippe Elsass wrote:

@Johann I don't want to sound inflammatory here, but you seem to have a personal issue with JS which clouds a bit your judgement ;)

 

Why don't you  give an answer to the reasons I presented *why* Haxe is the better tool for this job? Well, because you can't ;)

[Philippe Elsass]

I share your enthusiasm for Haxe being a better language but I value well tested code which already exists and can be reused using externs. Also using Haxe doesn't mean the code will be good, tested and maintained.

You can do good software engineering in JS and saying the opposite is a ridiculous claim. It however doesn't scale well and it requires a lot more discipline, and that's why are a few projects like Typescript and Flow which aim to solve some of the problems without pretending that JS devs are morons.

[Chris D]

Well all I want from a Haxe IDE is to use break points when debugging js and hxcpp.

Despite the awesome in Haxe, its a hard sell for mainstream developers to use if they have to give up their current tooling for refactoring, linting, and debugger that other tech offers.

Continuing the atom.io integration would be great given the community behind it.

Maybe checkout https://atom.io/packages/debugger

I saw source map support is in it's roadmap.

On Saturday, 24 January 2015 02:59:02 UTC+11, HaxeStudio pahArif wrote:

Hi all,

We've released Haxe Studio version 0.5. 

download it here

Changelog v0.5

============

• Complete rewrite in Javascript
  
• uses promises
  
• anyword completion always available
  
• Haxe completion uses CTRL/META + Space on '.' and '('
  
• Haxe completion have description
  
• Auto switch to next tab if the active tab are closed.
  
• increase speed by converting watch object to promises
  
• fix inconsistence in multi os by change menu to HTML
  
• new theme
  
• new 'new project' mechanism.
  
• new 'new project' template, openfl & haxeflixel
  
• add console
  
• Include About page
  
• Include Update page

[Marcelo de Moraes Serpa]

While I think debugger integration would be nice and not hard to implement for vim/emacs (maybe vaxe has this on the roadmap? cc @Justin), I think we already have good editors/IDEs out there, for example, the vaxe vim extension is actually pretty good! The rest can easily be added with some vimscript/elisp here and there. 

[Justin Donaldson]

Thanks for the kind words!  And thanks for trying vaxe.

https://github.com/jdonaldson/vaxe

Debugging is very difficult to do in vim.  It's single threaded, and requires some bizarre workarounds to interface with other processes.  I don't have a great plan for debugging, but I see recent efforts like : "vebugger" and it gives me some hope:

https://github.com/idanarye/vim-vebugger

For what it's worth, I think a common IDE toolkit could be used in a number of places.  I've already mentioned it to clemos and some sublime text folks.  I'd be further along with that project, but I'm having trouble getting a haxe target to work with vim.  My best bet is Lua for now, but that's not quite ready.