Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday December 04 2017, @04:16AM   Printer-friendly
from the but-is-it-round dept.

Submitted via IRC for TheMightyBuzzard

Light Table is a free, customizable, functional, and open-source IDE with a modern User Interface, plugin support, command pane, and connection manager

I'll stick with (g)vim personally but there's probably a few of you who'll find this interesting enough, if only to rag on it in the comments.

Source: https://www.fossmint.com/light-table-next-generation-open-source-ide-editor/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by LoRdTAW on Monday December 04 2017, @11:02PM (1 child)

    by LoRdTAW (3755) on Monday December 04 2017, @11:02PM (#605379) Journal

    Plenty of dynamic languages use multiple cores, even Clojure. The problem is the massive software stack in between the user and the actual application is a bloated mess. In the case of QtCreator, it's all c++ so the heavy lifting is done closer to the metal in native machine code using native libraries for graphics and everything else. That's about as fast as you can get.

    These newer IDE's are self contained cross-platform client-server web applications. They want cross-platform portability so that rules out compiled languages leaving us with VM languages. Those languages are slow by themselves unless they use native libraries via foreign function interfaces or other native interfaces to do the heavy lifting. But once again you have the portability problem so you have to stay within the VM. Okay, figured out how to run the code, now how do we display it on various operating systems or CPU arch's WITHOUT compiling anything? Answer: use a web browser. This necessitates integrating a web server into the back end code so the browser can talk to it. Most likely that happens via a web framework because someone has done it already so we drag in a shit load of dependencies. But wait! Clojure doesn't run in a browser so we have to write the web front end in HTMl, CSS and JS.

    In the end you have not one, but two VM's running two different halves of your code written in multiple languages. It's sloppy, lazy, wasteful, patently absurd and needs to stop.

    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by meustrus on Tuesday December 05 2017, @03:05PM

    by meustrus (4961) on Tuesday December 05 2017, @03:05PM (#605650)

    I'd say that "sloppy, lazy, wasteful" depends on the implementation. Yes, if you pull in all the frameworks and cobble them together like most client-server code these days, you will end up with a bloated mess. But it's possible to do things better than that. The problem is that it relies on the skill of the developer.

    It's possible, though, to create an application exactly as you describe and make it fast. Modeling your desktop app like an HTTP API-driven web app has the advantage of requiring everything to be asynchronous and (at the transmission level) stateless. These two limitations will make any application enormously more stable, and if you know how to work within them, parallelizable as well. You just need the discipline to leave the heavy frameworks on the shelf.

    --
    If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?