5 ms·

Most of the enterprise developers' job is connecting components together. I hate it. I hate modifying existing systems and hate connecting them together. It is

by nadam 15y ago

Most of the enterprise developers' job is connecting components together. I hate it. I hate modifying existing systems and hate connecting them together. It is usually hard, but the kind of hard which is not really fulfilling for me. It is about fighting with accidental complexity created by other people. It is not why I started programming when I was 12 years old. But this is what needs to be done: it is rational from business perspective. Of course at least in my side project I create something new from scratch (a component-based UI system painted on HTML5 Canvas).

chokma 15y ago
To continue the plumber metaphor: some systems are like black boxes with a lot of pipes sticking out - and they will route their raw sewage into your freshwater connector depending on barely documented and sometimes non-deterministic configuration parameters. The API of 10 year old closed source enterprise systems that have grown over time by buying this solution provider and that and where documented methods may work or not... shudders, no, that's not plumbing at all, that is more like playing Minecraft in a toxic waste dump.
js2 15y ago
I saw this somewhere the other day: tedious work is a necessary part of good software engineering.
fleitz 15y ago
It's not that difficult when you work with the right tools. Most of these problems boil down to a couple operations. map reduce filter Most of the data comes from a couple places: Some kind of SQL system Text files Webservices (of the JSON/XML/HTML variety) Most of the data goes back to the same places that it came from: Some kind of SQL system Text files Webservices (of the JSON/XML/HTML variety) All you need to make are four types: inputs: () -> Some<T> outputs: Seq<T> -> () pipes: Seq<T> -> Seq<Q> tees: Seq<T> -> () -> Seq<T> -> Seq<Q> (once partially applied the tee becomes a pipe) Using the usual sequence operators pretty much anything is possible with those inputs, outputs, and transforms (pipes) and you avoid a lot of overhead making data pipelines.
- watmough 15y ago
  Enterprise programming would have been a LOT more fun if I'd been allowed to use filter/map/reduce directly, instead of writing thousands of lines of C++. In the end, I just resigned to go and do iPhone software for a while. I suspect any one person only has a certain amount of programming in them, and you don't want to waste it.
  - fleitz 15y ago
    Haha, I hear ya on that. I worked on a .NET team, apparently that meant C# only, when F# came out I started writing F# until someone found out. (What's this Fsharp.exe that's crashing the build!?!?!?). Luckily, I had written so much (in terms C# code) that I was able to keep on writing in F# (technically, I wasn't allowed to create new F# code, but was allowed to maintain old code, oddly enough most new features made more sense as maintenance on the existing F# code).
    - watmough 15y ago
      Picture several thousand lines of C++ being reduced to 27 lines of Clojure and you get an idea. That's not to say that you couldn't do something similar in C++, but I've met like 4 really really good C++ programmers in about 15 years of programming, so no, it's unlikely to happen.
      - minikomi 15y ago
        What sort of tasks would make such a drastic reduction possible? Genuinely curious, having never written c++.
        fleitz 15y ago
        Higher-order functions. It's like the difference between calculus and arithmetic. If you're adding numbers together you're not going to see much difference. If you try to send a man to the moon... it's going to be a lot less code in a higher level language.
6ren 15y ago
What about those all enterprise integration tools (visual mappers for xml/relational/web-services) like Altova Mapforce, MicroSoft Biztalk Mapper and Stylus Studio? Oracle and IBM have similar tools. I haven't used these - but they look like they'd nail this problem. Is there a problem with them?
- nickik 15y ago
  I don't know these tools you mentions but I thing generally that these kinds of tools are the problem or at least they are treatments of the symptoms. Enterprise tools tend to make everything more complicated then it is (somebody else mentiond map/filter as a cure) and to help you fight this complexety you need even more complex tools. In the end you just have tonnes of Code and Tones of tools with tones of configuretions. Abstracting away ofer thing that are hard to abstract is a typical error these kinds of tools make. You cant just abstract away networks or databases. Sure a simple ORM is fine for most blogs but if you end up writting 30 lines of java code to do something you could have writen in 2 lines of sql something is not right. This video teaches the basic idea: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

by nadam 15y ago

chokma 15y ago

To continue the plumber metaphor: some systems are like black boxes with a lot of pipes sticking out - and they will route their raw sewage into your freshwater connector depending on barely documented and sometimes non-deterministic configuration parameters. The API of 10 year old closed source enterprise systems that have grown over time by buying this solution provider and that and where documented methods may work or not... shudders, no, that's not plumbing at all, that is more like playing Minecraft in a toxic waste dump.

js2 15y ago

I saw this somewhere the other day: tedious work is a necessary part of good software engineering.

fleitz 15y ago

It's not that difficult when you work with the right tools. Most of these problems boil down to a couple operations. map reduce filter Most of the data comes from a couple places: Some kind of SQL system Text files Webservices (of the JSON/XML/HTML variety) Most of the data goes back to the same places that it came from: Some kind of SQL system Text files Webservices (of the JSON/XML/HTML variety) All you need to make are four types: inputs: () -> Some<T> outputs: Seq<T> -> () pipes: Seq<T> -> Seq<Q> tees: Seq<T> -> () -> Seq<T> -> Seq<Q> (once partially applied the tee becomes a pipe) Using the usual sequence operators pretty much anything is possible with those inputs, outputs, and transforms (pipes) and you avoid a lot of overhead making data pipelines.

watmough 15y ago
Enterprise programming would have been a LOT more fun if I'd been allowed to use filter/map/reduce directly, instead of writing thousands of lines of C++. In the end, I just resigned to go and do iPhone software for a while. I suspect any one person only has a certain amount of programming in them, and you don't want to waste it.
- fleitz 15y ago
  Haha, I hear ya on that. I worked on a .NET team, apparently that meant C# only, when F# came out I started writing F# until someone found out. (What's this Fsharp.exe that's crashing the build!?!?!?). Luckily, I had written so much (in terms C# code) that I was able to keep on writing in F# (technically, I wasn't allowed to create new F# code, but was allowed to maintain old code, oddly enough most new features made more sense as maintenance on the existing F# code).
  - watmough 15y ago
    Picture several thousand lines of C++ being reduced to 27 lines of Clojure and you get an idea. That's not to say that you couldn't do something similar in C++, but I've met like 4 really really good C++ programmers in about 15 years of programming, so no, it's unlikely to happen.
    - minikomi 15y ago
      What sort of tasks would make such a drastic reduction possible? Genuinely curious, having never written c++.
      - fleitz 15y ago
        Higher-order functions. It's like the difference between calculus and arithmetic. If you're adding numbers together you're not going to see much difference. If you try to send a man to the moon... it's going to be a lot less code in a higher level language.

6ren 15y ago

What about those all enterprise integration tools (visual mappers for xml/relational/web-services) like Altova Mapforce, MicroSoft Biztalk Mapper and Stylus Studio? Oracle and IBM have similar tools. I haven't used these - but they look like they'd nail this problem. Is there a problem with them?

nickik 15y ago
I don't know these tools you mentions but I thing generally that these kinds of tools are the problem or at least they are treatments of the symptoms. Enterprise tools tend to make everything more complicated then it is (somebody else mentiond map/filter as a cure) and to help you fight this complexety you need even more complex tools. In the end you just have tonnes of Code and Tones of tools with tones of configuretions. Abstracting away ofer thing that are hard to abstract is a typical error these kinds of tools make. You cant just abstract away networks or databases. Sure a simple ORM is fine for most blogs but if you end up writting 30 lines of java code to do something you could have writen in 2 lines of sql something is not right. This video teaches the basic idea: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy