261–270 of 293 posts
Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…
Earlier quoted context omitted.
If they're so bad, why are so they popular? https://insights.stackoverflow.com/survey/2017#technology-mo...
Being popular isn't a synonym for quality.
I don't use Atom but I'm glad it exists. It improves on state-of-art in some areas and that benefits everyone.
Earlier quoted context omitted.
Not that hard nowadays, just use something like SDL to do the heavy lifting.
If it would be so easy as you paint it there would be lot more native applications. Unfortunately you can count them using your fingers.
Earlier quoted context omitted.
What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit
The question isn't "do I like these extensions?" It's "does Emacs let you build these extensions?" The Atom developers thought that providing this flexibility was important, which is at least in part why they used the technology they did.
The second question was "Where is this git-time-machine equivalent?" which is easier to answer when one knows what a user is expected to accomplish by using it, specifically the graphical part.
I think the Atom developers are doing the right thing now by focusing on performance more than useless graphics. Right now I recommend vscode to other people even though I'll probably always use emacs myself.
Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…
> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? Why would you build a text editor on top of a web browser engine? Who would think that is a good idea?. Of course it is not going to be performant, it is being used for something it was not designed for. On top of that, cross-platform apps built using the one stack are horrible. They never feel e…
They did, and the result wasn't that bad: http://www.jedit.org/
Earlier quoted context omitted.
If it would be so easy as you paint it there would be lot more native applications. Unfortunately you can count them using your fingers.
Just want to point out that SDL implementation would be native as in 'not running on top of VM', but not native as in 'good citizen of host OS'. It would use non-standard widgets, likely would have problems with keyboard shortcuts, clipboard handling, drag & drop integration and window resizing. Depends how much time devs spend re-implementing stuff that's already supported by OS.
Earlier quoted context omitted.
Forget Lazarus. There is no (finished) Cocoa for Mac. Development is not on Github. Syntax has no common style. Documentation is uneven. The whole ecosystem feels (well, is) dated. Of course, Lazarus/FPC is still quite nice. But to really shine and be a valid alternative, it would need a large infusion of money and manpower. Thus, don't hope too eagerly...
> There is no (finished) Cocoa for Mac. This is true but in practice the Carbon backend will work fine and if that isn't good enough you can use the Qt backend which uses Cocoa (but then you'd have to bundle Qt with your app which increases its distribution size a bit). To preempt a "then why not just use Qt" reaction, this isn't the same as using Qt since you can use the Win32 and Gtk backends in the other platforms…
>> Development is not on Github. >This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.
(Most important is, what the fpc/lazarus developers want). -- Many people likely don't want to bother/install the 'ugly and stupid' SVN nowadays and Lazarus/FPC looses all those potential contributors at once. I don't like monocultures either but GitHub (maybe Gitlab) is the pragmatic choice and imho helps to have/find contributors.
>> Syntax has no common style. >What do you mean? The IDE even provides formatting tools.
Comparing Lazarus, FPC, MSEgui and some component sets, I had the impression that there are many (small) differences, e.g. 'integer', 'Integer', 'INTEGER', where begin..ends are placed and many more 'non-conventions'...
Tool is good, but (imho) the issue is that there is no BDFL which would gently nudge towards a commonly agreed style guide. Likely not helpful is also that Pascal is not case-sensitive and that there are multiple modes (OBJFPC, DELPHI, FPC..)?
>> Documentation is uneven. >Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).
I don't want to complain. Core FPC docu is high-quality, written in Tex. But I found it difficult to get an overview: which are the relevant pdf's/links, where is the source for it, how would I contribute or report an error? For a quick shallow fix, it seems too complicated: Tex, xml; inline help, huge separate svn docu project; FPDoc generator. Contrast this to many environments where you can quickly fix a typo or phrase in the browser and the project gets a PR.
>> The whole ecosystem feels (well, is) dated. >Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.
Difficult to be specific. If you e.g. look at go (golang.org/), rust (www.rust-lang.org), julia (julialang.org) and/or haskell (haskell.org) and some of their tool-choices, it feels for me very different than FPC/Lazarus. This is not mudling, it's just a realistic look at the situation. Dated also doesn't mean that it wouldn't work any more.
It is imho a problem if e.g. there is newpascal.com site with a more modern feel instead of the old trusted projects moving to a more modern approach. Don't know details but this choice raises the complexity for a user as it is not clear, what to choose.
>> But to really shine and be a valid alternative, it would need a large infusion of money and manpower. >Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.
Do you have examples for such companies / situations? As the code is mostly GPL-2 (components LGPL2 with link-exception or MPL), it seems to be difficult for a company to take over. And personally I wish that there were steerings towards a more uniform and easier-to-enter 'FPC/Lazarus-world'.
>The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.
Yes I hope things improve with new blood. For the 'Pascal universe' as a whole, lack of developers means 'not attractive enough'. As I really like the language I would blame the choice/proliferation of 'dated stuff' to be a contributing factor.
Last but not least, Lazarus worked well last November when I tried it out again. I was positively surprised. Nevertheless one has to have realistic hopes...
Earlier quoted context omitted.
Personally, Atom is not my editor of choice (team Sublime!), but I really hope Atom succeeds. I do love it's hackability, and I would much rather have my plugins in JS, but alas, it's just not fast enough for me, yet. However I held onto Textmate until 2010 and Sublime wore me down, so I'm a laggard as well. So no negativity from me, because I just want a great editor that I can control and hack on. But I'll be real,…
This may sound like heresy but I seriously encourage checking out today's version of Visual Studio. I dev on Ruby and I am a hardcore Sublime user, which is about as far away from Microsoft-friendly as you can get, and I have been really impressed by it. Their app store is advanced, and crucially they allow Visual Studio to be setup with key bindings that match Sublime's, meaning switching over is really easy with al…
I'll have to look into the plugin API, though. I'd have to convert a lot of custom plugins, but that could be a fun weekend distraction.
Earlier quoted context omitted.
Being popular isn't a synonym for quality.
It proves that there was a need not met by other options. Do you resent Atom developers for giving away free tool that you consider subpar? Or are you angry at its userbase for choosing Atom over your preferred option? I don't use Atom but I'm glad it exists. It improves on state-of-art in some areas and that benefits everyone.
This is why good tools are only available to enterprise customers, the only ones willing to pay for their tools, just like in other professions.
There is nothing in Atom that I can consider state of the art.
Earlier quoted context omitted.
How does that follow? The boring technology in AI/ML is C++. Which is why TensorFlow etc. have a boring & hard C++ core, and a lovely & easy Python layer that transmits the computational graph to the core. Electron is similar: a boring & hard Chromium C++ core, and a lovely & easy JS layer. What pains me is that there is no reason to include libraries we don't use . Each Electron embeds a large amount of memory-consu…
Python is a boring technology. It's a 10+ years old language, like ~20 years behind cutting edge programming language research and implementation. Also, as for the programming style it encourages, it strongly nudges you against any "cool" way of programming: even the most basic kinds of functional programming is something you end up avoiding in P and "dumbing down" your code to more procedural idioms, and OOP over-ov…