7 ms·

my typical experience with these kinds of things: I start looking at the source code, and the code is actually simple and short, the logic is easy to follow (ma

by slx26 7y ago

my typical experience with these kinds of things: I start looking at the source code, and the code is actually simple and short, the logic is easy to follow (make a grid, allow and process formulas in cells, display the grid and some additional edit-mode display if you are editing a cell)... but then I start seeing dependencies, references to other frameworks and multiple languages, libraries... and all that looks so confusing! the dependencies require at least an order of magnitude more knowledge to be understood or used effectively than what we are being shown in the post; that's the really tricky part to me. don't mean to criticize that, those are probably very powerful tools that in most cases you want to know about and use (if you are working in that specific environment), but it's like... are those 100 lines of F# even that important? writing your own excel sounds nice, but I feel it's more "how to glue a bit of F# logic to a web-compatible UI" (well, yeah, one could argue those are really the same things). > "The final spreadsheet application is quite simple" Is it? I easily understand the logic of the F# code, but I couldn't make another "similar" application so easily unless I was just copying the dependencies. I wouldn't really know what I'm doing, maybe it's not so simple! (this isn't meant to be a criticism to the article itself, I just wanted to share this uneasiness I get when checking some code I don't know much about that's presented as "simple"/"short"/...)

aardvark291 7y ago
I remember feeling this in regards to some early "rapid application development" software in the 90's (Visual Basic or Borland Delphi or something). "Look how easy it is to make a text editor!" - Drag the "text editor component" over a blank form. Look how easy it is to make a web browser! - Drag the "web browser component". Or, maybe it was in PHP, "As an example, here's code to format an integer as Roman numerals." Oh, that sounds interesting... Expecting a cool algorithm, then discover it's (for some reason) a standard library function.
- empath75 7y ago
  Why solve problems other people have already solved?
  - DennisP 7y ago
    That's not really the point. If someone says "look how easy it is to do X," then I want to see them doing X from scratch, so I can get an idea how hard it would be to use the language for my unsolved problems. If it turns out they're just dragging in prewritten code, that's useless to me.
    - klez 7y ago
      Depends. If they told me "look how easy it is to apply this function to a certain subset of the elements of this array" and they show me map and filter instead of a for loop I would be all for it, even if it's "prewritten" code. But I get the example about roman numerals, editors and browsers.
      - wolco 7y ago
        The browser drop-in was extremely useful. I made a blazing fast browser had view-source as a first class button was able to add in my favourites as icons. Better yet I could make the browser fullscreen. I would consider it a browser that used an engine. Now a days everyone but firefox is using WebKit.. not much of a difference. Curious how you would do that today without vb.net
        dual_basis 7y ago
        I guess the point is that you can't really say you've made a browser. It's like bringing store-bought brownies to a party and claiming you made them yourself.
        Crinus 7y ago
        But he made the browser - the browser is the application itself (what he made) - not the browser's engine. Saying that he didn't make a browser is like saying Notepad++'s author didn't really made an editor because he used Scintilla.
  - willtim 7y ago
- Crinus 7y ago
  > "Look how easy it is to make a text editor!" - Drag the "text editor component" over a blank form. Look how easy it is to make a web browser! - Drag the "web browser component". But it is easy to make those things using those tools you mentioned and for the problems they were intended to solve these systems work perfectly fine without you needing to know how they work underneath. However sometimes you need more than that and you do need to open the box and see what is inside and how to work with it. Both VB and Delphi allowed that and at least Delphi had extensive documentation (and full framework source code) about all aspects of it (VB was a bit different in that it didn't had documentation for itself but as it was built on full Win32/COM tech the knowledge was still part of the Microsoft tech - e.g. the MSDN CDs in VS6 had everything you needed to know - though Delphi was probably better on that front as a self-contained tool). And escape hatches were placed all the way down (e.g. getting a window handle was just a property in both systems, you could directly call Win32 API functions directly from both systems, interfacing DLLs was trivial, making custom controls was also trivial - at least in later versions of both systems, etc). Last time i used PHP was many many years ago so i cannot judge that, but from what i remember it wasn't like VB6/Delphi that built on top of an existing system (for all their nice facades, they were inherently related to Win32 - an issue that still exists for LCL/Lazarus that reimplements VCL as a cross-platform library using native widgets) but instead was a system of its own that provided a raw(ish) interface to existing libraries through its module system.
DennisP 7y ago
From a quick skim, it looks like the only dependencies are the basic UI library Elmish, and a parser combinator lib that itself is only 129 lines.
- slx26 7y ago
  Nuget.Config, package-lock.json, package.json, webpack.config.js, yarn.lock, spreadsheet.fsproj, mentions to Fable and Elmish, Visual Studio, C#, Microsoft .NET, Javascript, and a 200 lines .gitignore file, pretty well formatted. You might argue that if I tried to become an F# developer I would get to know most of those on days one and two, and I wouldn't have to worry about many of them as they are just auto-generated or whatever. And I would agree. But those are the files that exist on the repository and that the developer needed to make this project work, despite making a "toy project". And they are there for a reason, and are related to other, way more complex pieces of software. Not like there's anything inherently wrong with it, but that's the "hidden" knowledge and complexity I was commenting about. Not something that's particular to F#, though.
  - yawaramin 7y ago
    > Not something that's particular to F#, though. So what's the point of the comment? You could make this exact same comment almost any time someone posts any cool project they made. 'Look at all the dependencies! Project tooling, IDE, runtime platform, version control, libraries.' It doesn't add anything useful to the discussion about a specific project.
    - slx26 7y ago
      Please reread my original comment. I'll try to summarize: my point is not about a specific project, but rather that sometimes we talk about / sell something as being easy, short or simple without accounting for all the things you said: project tooling, IDE, version control, etc., while all that is indeed part of the software complexity. I was just pointing out that in some cases we may be obviating that too much. Yes, I could have written this in any other project that made remarks about some code being simple or easy when (imo) it's not. I never criticised tooling, libraries, etc, themselves, I even made that explicit a couple times, and it's true I've said that it might happen in all languages. That still doesn't mean it's equally bad in all languages, or that it can't be improved, etc. I wasn't trying to start a discussion about this, it just happened. It was just a thought that I transcribed as a comment, in case it gave something to think about to someone.
brianpgordon 7y ago
Just to give my perspective, I read it totally differently. The impressive part to me was the F# core doing spreadsheety things, and the rest felt like incidental view logic that had to be covered for the sake of completeness but wasn't really important. I thought the fact that the demo is embedded right in the page was incredibly cool because it let you poke the logic interactively, but I wasn't too concerned with how it was done.
tpetricek 7y ago
I'm this case, there is virtual-dom dependency, one more file with some code to simplify the creation of UI and whatever Fable (F# to JS) provides. So it's not 100 lines, but there is a lot less dependencies than you'd expect.

by slx26 7y ago

aardvark291 7y ago

I remember feeling this in regards to some early "rapid application development" software in the 90's (Visual Basic or Borland Delphi or something). "Look how easy it is to make a text editor!" - Drag the "text editor component" over a blank form. Look how easy it is to make a web browser! - Drag the "web browser component". Or, maybe it was in PHP, "As an example, here's code to format an integer as Roman numerals." Oh, that sounds interesting... Expecting a cool algorithm, then discover it's (for some reason) a standard library function.

empath75 7y ago
Why solve problems other people have already solved?
- DennisP 7y ago
  That's not really the point. If someone says "look how easy it is to do X," then I want to see them doing X from scratch, so I can get an idea how hard it would be to use the language for my unsolved problems. If it turns out they're just dragging in prewritten code, that's useless to me.
  - klez 7y ago
    Depends. If they told me "look how easy it is to apply this function to a certain subset of the elements of this array" and they show me map and filter instead of a for loop I would be all for it, even if it's "prewritten" code. But I get the example about roman numerals, editors and browsers.
    - wolco 7y ago
      The browser drop-in was extremely useful. I made a blazing fast browser had view-source as a first class button was able to add in my favourites as icons. Better yet I could make the browser fullscreen. I would consider it a browser that used an engine. Now a days everyone but firefox is using WebKit.. not much of a difference. Curious how you would do that today without vb.net
      - dual_basis 7y ago
        I guess the point is that you can't really say you've made a browser. It's like bringing store-bought brownies to a party and claiming you made them yourself.
        Crinus 7y ago
        But he made the browser - the browser is the application itself (what he made) - not the browser's engine. Saying that he didn't make a browser is like saying Notepad++'s author didn't really made an editor because he used Scintilla.
- willtim 7y ago
Crinus 7y ago
> "Look how easy it is to make a text editor!" - Drag the "text editor component" over a blank form. Look how easy it is to make a web browser! - Drag the "web browser component". But it is easy to make those things using those tools you mentioned and for the problems they were intended to solve these systems work perfectly fine without you needing to know how they work underneath. However sometimes you need more than that and you do need to open the box and see what is inside and how to work with it. Both VB and Delphi allowed that and at least Delphi had extensive documentation (and full framework source code) about all aspects of it (VB was a bit different in that it didn't had documentation for itself but as it was built on full Win32/COM tech the knowledge was still part of the Microsoft tech - e.g. the MSDN CDs in VS6 had everything you needed to know - though Delphi was probably better on that front as a self-contained tool). And escape hatches were placed all the way down (e.g. getting a window handle was just a property in both systems, you could directly call Win32 API functions directly from both systems, interfacing DLLs was trivial, making custom controls was also trivial - at least in later versions of both systems, etc). Last time i used PHP was many many years ago so i cannot judge that, but from what i remember it wasn't like VB6/Delphi that built on top of an existing system (for all their nice facades, they were inherently related to Win32 - an issue that still exists for LCL/Lazarus that reimplements VCL as a cross-platform library using native widgets) but instead was a system of its own that provided a raw(ish) interface to existing libraries through its module system.

DennisP 7y ago

From a quick skim, it looks like the only dependencies are the basic UI library Elmish, and a parser combinator lib that itself is only 129 lines.

slx26 7y ago
Nuget.Config, package-lock.json, package.json, webpack.config.js, yarn.lock, spreadsheet.fsproj, mentions to Fable and Elmish, Visual Studio, C#, Microsoft .NET, Javascript, and a 200 lines .gitignore file, pretty well formatted. You might argue that if I tried to become an F# developer I would get to know most of those on days one and two, and I wouldn't have to worry about many of them as they are just auto-generated or whatever. And I would agree. But those are the files that exist on the repository and that the developer needed to make this project work, despite making a "toy project". And they are there for a reason, and are related to other, way more complex pieces of software. Not like there's anything inherently wrong with it, but that's the "hidden" knowledge and complexity I was commenting about. Not something that's particular to F#, though.
- yawaramin 7y ago
  > Not something that's particular to F#, though. So what's the point of the comment? You could make this exact same comment almost any time someone posts any cool project they made. 'Look at all the dependencies! Project tooling, IDE, runtime platform, version control, libraries.' It doesn't add anything useful to the discussion about a specific project.
  - slx26 7y ago
    Please reread my original comment. I'll try to summarize: my point is not about a specific project, but rather that sometimes we talk about / sell something as being easy, short or simple without accounting for all the things you said: project tooling, IDE, version control, etc., while all that is indeed part of the software complexity. I was just pointing out that in some cases we may be obviating that too much. Yes, I could have written this in any other project that made remarks about some code being simple or easy when (imo) it's not. I never criticised tooling, libraries, etc, themselves, I even made that explicit a couple times, and it's true I've said that it might happen in all languages. That still doesn't mean it's equally bad in all languages, or that it can't be improved, etc. I wasn't trying to start a discussion about this, it just happened. It was just a thought that I transcribed as a comment, in case it gave something to think about to someone.

brianpgordon 7y ago

Just to give my perspective, I read it totally differently. The impressive part to me was the F# core doing spreadsheety things, and the rest felt like incidental view logic that had to be covered for the sake of completeness but wasn't really important. I thought the fact that the demo is embedded right in the page was incredibly cool because it let you poke the logic interactively, but I wasn't too concerned with how it was done.

tpetricek 7y ago

I'm this case, there is virtual-dom dependency, one more file with some code to simplify the creation of UI and whatever Fable (F# to JS) provides. So it's not 100 lines, but there is a lot less dependencies than you'd expect.